Provisioner asks the backend, not memory, whether a consumer is still there (hq issue 120) #7

2026-09-25T22:53:28Z

jschoubben commented

2026-09-25 22:53:28 +00:00

The problem. The harness skipped any consumer whose login, password and values were unchanged. It trusted its memory forever, so a backend that forgot a consumer while the provisioner kept running was never provisioned again. Nothing reported it. This is hq issue 120 (hq PR #114).

The change.

New adapter method. Adapter.holds?(p: Provision): Promise<boolean> is optional and read-only.
How often. It is asked for every applied consumer every verifyEveryMs, which defaults to 60 000 ms.
What the answer does.
- false: the consumer is applied again on the same pass, and the log says why.
- It throws: nothing is re-applied, and it's asked again next time. Being unable to ask is not evidence of loss.
Adapters without holds are unchanged: they are still trusted from memory.
Version goes to 0.1.1, which the catalogue's ^0.1.0 pins accept.

Tests. 8 of 8 pass. Two are new:

A backend that forgets. It is asked while it holds the consumer (no second create), and it is healed after it forgets. An adapter without holds stays forgotten, as before.
A backend that can't be asked. It is never re-created.

Follow-up. mesh-catalog's redis adapter implements holds in its own PR and needs this published first.

**The problem.** The harness skipped any consumer whose login, password and values were unchanged. It trusted its memory forever, so a backend that forgot a consumer while the provisioner kept running was never provisioned again. Nothing reported it. This is hq issue 120 (hq PR #114). **The change.** - **New adapter method.** `Adapter.holds?(p: Provision): Promise<boolean>` is optional and read-only. - **How often.** It is asked for every applied consumer every `verifyEveryMs`, which defaults to 60 000 ms. - **What the answer does.** - `false`: the consumer is applied again on the same pass, and the log says why. - It throws: nothing is re-applied, and it's asked again next time. Being unable to ask is not evidence of loss. - **Adapters without `holds`** are unchanged: they are still trusted from memory. - **Version** goes to 0.1.1, which the catalogue's `^0.1.0` pins accept. **Tests.** 8 of 8 pass. Two are new: - **A backend that forgets.** It is asked while it holds the consumer (no second create), and it is healed after it forgets. An adapter without `holds` stays forgotten, as before. - **A backend that can't be asked.** It is never re-created. **Follow-up.** mesh-catalog's redis adapter implements `holds` in its own PR and needs this published first.

jschoubben added 1 commit 2026-09-25 22:53:28 +00:00

Provisioner asks the backend, not memory, whether a consumer is still there 7976510028

An optional holds() on the adapter is asked for every applied consumer
every minute; false applies it again. A backend that forgets what it was
given while the provisioner runs (hq issue 120) is healed within a
minute instead of failing its consumers in silence. Unable to ask is not
treated as loss. Adapters without holds() behave as before.

jschoubben added 1 commit 2026-09-25 23:24:34 +00:00

Bound holds: a timeout, a brake, and no password in the log 3d0165559a

A check that hangs no longer stalls every consumer: it times out after
30s and counts as could-not-ask, and the rest of that pass is not asked.
A consumer still not held after being applied again is checked at
doubling intervals up to an hour, and said loudly, so an adapter whose
create and holds disagree costs one re-apply an hour, not one a minute.
The consumer's password is scrubbed from every error the harness logs.

jschoubben added 1 commit 2026-09-25 23:30:17 +00:00

Brake counts only successful re-applies; only a timeout ends a pass 3192491df6

A lost consumer whose re-apply fails is retried at the next check with
its count unchanged, instead of waiting out a backoff meant for adapters
whose create and holds disagree. A check that fails for one consumer no
longer stops checking the consumers after it; only a timeout does.

jschoubben merged commit ffe49b5928 into main

2026-09-25 23:30:24 +00:00

jschoubben deleted branch fix/120-a-provisioner-checks-what-is-there

2026-09-25 23:30:24 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-sdk#7