Raise the assigner's asks on the operator channel, lift a hold once every node runs it healthy, and keep its cause (issue 1906) #40

2026-10-25T13:24:21Z

mesh-tools commented

2026-10-25 13:24:21 +00:00

On 2026-10-25 seven modules (ca-trust, fail2ban, mesh-host, mesh-provisioner-client, node-tools, pacman, restic) were held on all four machines and no ask reached the operator: the assigner wrote HoldAsk/RestoreAsk to mesh-delivery-assigner_asks, but the teller's OnAssignerAsk only filled answers given in the delivery view. A hold also stayed after every machine ran the fingerprint healthy, and kept no cause.

What changes:

The teller raises every assigner ask (hold, restore, backup, record) on operator-channel through the merge-ask path; the warrant is written by compare-and-set under the ask's key, where pass.go reads it. At most 2 assigner asks are open at once (assigner.open in the teller's asked bucket), so a merge ask always has room; an ask answered in the view or taken away is cancelled at the router.
The assigner lifts a hold once every node with a have runs that fingerprint healthy, says the cleared condition once, and removes the ask. The asking number is the hold's time, so a hold written again after a lift and a restart is asked again.
An answer counts only for the asking it answered (warrant id before the @ equals the current ask's id).
Held.Words keeps the cause: health, phase, when, the node's words.

Acceptance: issue 1906 notes 21-22 (1906/H1-H5). Tests (each seen failing first): assignerasks_test.go (6 + TestABurstOfHoldsLeavesRoomForAMergeAsk), TestTellerRaisesAnAssignerAskAndWritesTheOperatorsAnswer (integration), TestAHoldIsLiftedOnceEveryNodeRunsItHealthy (unit + integration), TestAHoldAskedAgainAfterALiftAndARestartHasANewID, TestAHoldWrittenAgainAfterALiftAndARestartIsAskedAgain (integration), TestAnAnswerCountsOnlyForTheAskingItAnswered, TestAHoldOfAFailureWithoutWordsSaysSo.

Note: a hold of the same version lifted and held again within the same second keeps its id (reviewer: unlikely, not blocking).

Tries: try-1792934224536865823 passed on 7ef796b0.
Reviewed-by: reviewer-r6m@shanks at 7ef796b04b
Pushed-by: lead-47@shanks

On 2026-10-25 seven modules (ca-trust, fail2ban, mesh-host, mesh-provisioner-client, node-tools, pacman, restic) were held on all four machines and no ask reached the operator: the assigner wrote HoldAsk/RestoreAsk to mesh-delivery-assigner_asks, but the teller's OnAssignerAsk only filled answers given in the delivery view. A hold also stayed after every machine ran the fingerprint healthy, and kept no cause. What changes: 1. The teller raises every assigner ask (hold, restore, backup, record) on operator-channel through the merge-ask path; the warrant is written by compare-and-set under the ask's key, where pass.go reads it. At most 2 assigner asks are open at once (assigner.open in the teller's asked bucket), so a merge ask always has room; an ask answered in the view or taken away is cancelled at the router. 2. The assigner lifts a hold once every node with a have runs that fingerprint healthy, says the cleared condition once, and removes the ask. The asking number is the hold's time, so a hold written again after a lift and a restart is asked again. 3. An answer counts only for the asking it answered (warrant id before the @ equals the current ask's id). 4. Held.Words keeps the cause: health, phase, when, the node's words. Acceptance: issue 1906 notes 21-22 (1906/H1-H5). Tests (each seen failing first): assignerasks_test.go (6 + TestABurstOfHoldsLeavesRoomForAMergeAsk), TestTellerRaisesAnAssignerAskAndWritesTheOperatorsAnswer (integration), TestAHoldIsLiftedOnceEveryNodeRunsItHealthy (unit + integration), TestAHoldAskedAgainAfterALiftAndARestartHasANewID, TestAHoldWrittenAgainAfterALiftAndARestartIsAskedAgain (integration), TestAnAnswerCountsOnlyForTheAskingItAnswered, TestAHoldOfAFailureWithoutWordsSaysSo. Note: a hold of the same version lifted and held again within the same second keeps its id (reviewer: unlikely, not blocking). Tries: try-1792934224536865823 passed on 7ef796b0. Reviewed-by: reviewer-r6m@shanks at 7ef796b04b923325afcf2f032aa4a1bfdfcb6ead Pushed-by: lead-47@shanks

mesh-tools added 3 commits 2026-10-25 13:24:22 +00:00

Raise the assigner's asks on the operator channel, lift a hold once every node runs it healthy, keep the hold's cause (issue 1906) 6b63f13da6

Seven modules stayed held on every machine and the operator was never asked:
the teller only filled assigner asks from the view, a single failed check held
a fingerprint for good, and the held record kept no cause. The teller now asks
every assigner ask as it asks merge asks and writes the phone's answer under
the ask's key; the assigner lifts a hold whose fingerprint runs healthy on
every node that runs the module, says so once and takes its ask back; the held
record names health, phase, when and the node's words.

Ask a hold again after a restart, leave a merge ask room, take an answer only for its asking (issue 1906, review) ec93585736

A hold written again after a lift and a restart reused its first ask id, which
the router drops; the hold's time is now its asking. Seven holds could take the
router's three places for the teller and keep a merge Approve from being asked;
the teller keeps at most two assigner asks open. A release or keep answered for
one hold carried over to a later hold of the same fingerprint; an answer now
counts only for the asking its warrant names.

Format the assigner's integration test (issue 1906)

mesh/check pass 7ef796b04b92 on 97e605edb0ad | unit 154 run, 404 kept | integration 164 run, 469 kept | composition passed on 2 machines

mesh/delivery merged: source.main moved to novox/mesh-delivery@97e605edb0ad

Details

7ef796b04b

mesh-tools commented

2026-10-25 13:24:26 +00:00

Delivery novox/mesh-delivery@7ef796b04b92 — merged since 2026-10-25T13:27:34Z

Source — source.main moved to novox/mesh-delivery@97e605edb0. Whether it reached the machines is mesh-delivery-view's, derived from source.main, the wants and the haves.

Transitions

2026-10-25 13:24 (new) → proposed (announced): novox/mesh-delivery#40's head announced
2026-10-25 13:26 proposed → ready (accepted): a verdict names this commit and the trunk's head as its trunk commit, the gate passed or warned, and the repository's own check did not fail
2026-10-25 13:27 ready → merged (merged): on the trunk its modules follow: merged there

The commit's note under refs/notes/mesh-plan keeps every transition of this change up to its merge: git log --notes=mesh-plan.

**Delivery** `novox/mesh-delivery@7ef796b04b92` — **merged** since 2026-10-25T13:27:34Z **Source** — source.main moved to novox/mesh-delivery@97e605edb0ad. Whether it reached the machines is `mesh-delivery-view`'s, derived from `source.main`, the wants and the haves. **Transitions** - 2026-10-25 13:24 (new) → proposed (announced): novox/mesh-delivery#40's head announced - 2026-10-25 13:26 proposed → ready (accepted): a verdict names this commit and the trunk's head as its trunk commit, the gate passed or warned, and the repository's own check did not fail - 2026-10-25 13:27 ready → merged (merged): on the trunk its modules follow: merged there The commit's note under `refs/notes/mesh-plan` keeps every transition of this change up to its merge: `git log --notes=mesh-plan`.

mesh-tools merged commit 97e605edb0 into main

2026-10-25 13:27:30 +00:00

mesh-tools deleted branch fix/r6-hold-asks

2026-10-25 13:27:31 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-delivery#40