Assigner: take away hold, restore and record asks whose fingerprint the trunk left behind (issue 1906) #60

2026-10-26T09:38:33Z

mesh-tools commented

2026-10-26 09:38:33 +00:00

Issue 1906 (note 28): an assigner ask outlived its fingerprint. A restore ask for nextcloud on novox at an old fingerprint stayed offered to the operator since 2026-10-25 16:15 while nextcloud ran the trunk fingerprint healthy; lift() never took away the restore asks of the lifted fingerprint, and no pass took away a hold, restore or record ask the trunk had left behind.

What changes (mesh-delivery-assigner, pass.go):

Each pass takes away a hold or restore ask whose module left the trunk or whose fingerprint is not the trunk's; it keeps the held record (the memory that the fingerprint failed, so a revert to it is asked again) and clears only its condition, which is raised again on a return.
A record ask is taken away only when its module left the trunk or its digest is the composition of none of the fingerprints the node can still want (trunk, its want, its have), all read; unread keeps it (ADR 0545's held-back nodes keep their asks).
lift() also takes away the restore asks of the lifted fingerprint on every node.
The teller already withdraws an ask at the router when its key goes (OnAssignerAskGone), so the operator stops seeing it.

Tests: one table-driven test and one pass-level test (a held-back node's record ask survives two passes and its yes moves the want); both fail on the round-1 heads. Try try-1793007301404384331 passed (unit and integration, 2m43s).

Test budget (bent, said): the repository is over the 50/500 budget today; this change adds one top-level unit test and table cases, no integration test. The budget shrink is issue 1921's.

Known leftover (note on issue 1906): if the clear of an old fingerprint's condition fails once, it stays raised until a restart.

Reviewed-by: review-asks@shanks at 769dab43a2

Issue 1906 (note 28): an assigner ask outlived its fingerprint. A restore ask for nextcloud on novox at an old fingerprint stayed offered to the operator since 2026-10-25 16:15 while nextcloud ran the trunk fingerprint healthy; lift() never took away the restore asks of the lifted fingerprint, and no pass took away a hold, restore or record ask the trunk had left behind. What changes (mesh-delivery-assigner, pass.go): - Each pass takes away a hold or restore ask whose module left the trunk or whose fingerprint is not the trunk's; it keeps the held record (the memory that the fingerprint failed, so a revert to it is asked again) and clears only its condition, which is raised again on a return. - A record ask is taken away only when its module left the trunk or its digest is the composition of none of the fingerprints the node can still want (trunk, its want, its have), all read; unread keeps it (ADR 0545's held-back nodes keep their asks). - lift() also takes away the restore asks of the lifted fingerprint on every node. - The teller already withdraws an ask at the router when its key goes (OnAssignerAskGone), so the operator stops seeing it. Tests: one table-driven test and one pass-level test (a held-back node's record ask survives two passes and its yes moves the want); both fail on the round-1 heads. Try try-1793007301404384331 passed (unit and integration, 2m43s). Test budget (bent, said): the repository is over the 50/500 budget today; this change adds one top-level unit test and table cases, no integration test. The budget shrink is issue 1921's. Known leftover (note on issue 1906): if the clear of an old fingerprint's condition fails once, it stays raised until a restart. Reviewed-by: review-asks@shanks at 769dab43a24d71443eff2aa41ee2af011edebedb

mesh-tools added 3 commits 2026-10-26 09:38:33 +00:00

Assigner: take away hold, restore and record asks whose fingerprint the trunk left behind (issue 1906) 07dee528c5

An ask outlived its fingerprint: a lift left the restore asks of its fingerprint on every node,
and no pass removed an ask of a fingerprint that is no longer the module's trunk fingerprint,
so the operator kept being asked about a module that runs the trunk healthy. Each pass now
takes those asks away (the teller then withdraws the router ask), and a lift takes the restore
asks of its fingerprint. Nothing is taken away while the trunk or a composition is unread.

Assigner: keep a held-back node's record ask, and clear the held record and condition of a stale hold (issue 1906) 98a05997ae

Review round 1: a record ask is about the composition of any fingerprint a node may still want
(trunk, want, have), not only the trunk's, so deleting it looped with the wants rule that asks it
again and the operator was never asked. It is now stale only when the module left the trunk or no
read composition of those fingerprints has its digest. A hold or restore ask taken away as stale
also takes its held record and clears its held condition.

Assigner: keep the held record of a fingerprint whose asks went stale (issue 1906)

mesh/delivery merged: source.main moved to novox/mesh-delivery@2f697216eee4

Details

mesh/check pass 769dab43a24d on 2f697216eee4 | unit 168 run, 488 kept | integration 178 run, 554 kept | composition passed on ace

769dab43a2

The held record is the memory that a fingerprint failed (ADR 0408 section 4); a revert returns the
trunk to exactly it, and without the key rule 3 would move the canary onto the failed build with
nothing asked. A stale hold ask now clears only the condition (raised again on a revisit), and the
hold is asked again under a new asking. Also read the single want key for a record ask.

mesh-tools commented

2026-10-26 09:38:36 +00:00

Delivery novox/mesh-delivery@769dab43a24d — merged since 2026-10-26T09:49:24Z

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

Transitions

2026-10-26 09:38 (new) → proposed (announced): novox/mesh-delivery#60's head announced
2026-10-26 09:38 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; or the check gates no merge (check-gates-merge false)
2026-10-26 09:49 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@769dab43a24d` — **merged** since 2026-10-26T09:49:24Z **Source** — source.main moved to novox/mesh-delivery@2f697216eee4. Whether it reached the machines is `mesh-delivery-view`'s, derived from `source.main`, the wants and the haves. **Transitions** - 2026-10-26 09:38 (new) → proposed (announced): novox/mesh-delivery#60's head announced - 2026-10-26 09:38 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; or the check gates no merge (check-gates-merge false) - 2026-10-26 09:49 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 2f697216ee into main

2026-10-26 09:49:23 +00:00

mesh-tools deleted branch fix/1906-stale-asks

2026-10-26 09:49:23 +00:00

mesh-tools referenced this pull request

2026-10-26 10:08:23 +00:00

Assigner: take a stale ask away only once its held condition's clear was said, so a failed clear is retried (issue 1906) #61

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-delivery#60