Apply the revision of a composition its want names, read from the key's history, when the latest has another digest (issue 1945) #139

2026-10-25T11:54:06Z

mesh-tools commented

2026-10-25 11:54:06 +00:00

On shanks and g14, node-tools stayed unapplied: its want names the digest of an earlier composition at the same fingerprint (the assigner keeps a held or unchanged want whole), the controller had since rewritten the key, and the node-engine applies only a key's latest value, so "nothing is applied until they agree" for ever, the module never turns healthy and its hold never lifts. ADR 0539's design expects the node to apply the revision its want names; the bucket keeps history and the node holds the grant to read it.

What changes:

When the key's latest composition is missing, unreadable, or carries another digest than the want names, the agent reads the key's revisions (Session.KVHistory, bounded to 10 s) and applies the newest one whose verified digest the want names. Unsigned, foreign-signed, other-digest, deleted and purged revisions are skipped. When none matches, the existing "digests disagree" path says so once and waits; nothing loops.
The composition a module was applied from is kept, so a module running an older revision is still held out of the others' applies and counts in Running.
internal/witness's runFrom waits (bounded, 5 s) until /proc//exe names the image: TestAProcessRunsFromABuildDeletedUnderIt failed once on a try reading /proc before the process showed.

Tests: TestTheRevisionAWantNamesIsAppliedFromHistory (failed first); TestNatsAKeysRevisionsAreReadBack (integration, embedded bus: revisions oldest first, delete marker, purge, a key that never was).

Tries: try-1792929068013610028 passed on 11a63579 (1010 unit, 1015 integration).
Reviewed-by: reviewer-r6m@shanks at 11a635796d
Pushed-by: lead-47@shanks

On shanks and g14, node-tools stayed unapplied: its want names the digest of an earlier composition at the same fingerprint (the assigner keeps a held or unchanged want whole), the controller had since rewritten the key, and the node-engine applies only a key's latest value, so "nothing is applied until they agree" for ever, the module never turns healthy and its hold never lifts. ADR 0539's design expects the node to apply the revision its want names; the bucket keeps history and the node holds the grant to read it. What changes: 1. When the key's latest composition is missing, unreadable, or carries another digest than the want names, the agent reads the key's revisions (Session.KVHistory, bounded to 10 s) and applies the newest one whose verified digest the want names. Unsigned, foreign-signed, other-digest, deleted and purged revisions are skipped. When none matches, the existing "digests disagree" path says so once and waits; nothing loops. 2. The composition a module was applied from is kept, so a module running an older revision is still held out of the others' applies and counts in Running. 3. internal/witness's runFrom waits (bounded, 5 s) until /proc/<pid>/exe names the image: TestAProcessRunsFromABuildDeletedUnderIt failed once on a try reading /proc before the process showed. Tests: TestTheRevisionAWantNamesIsAppliedFromHistory (failed first); TestNatsAKeysRevisionsAreReadBack (integration, embedded bus: revisions oldest first, delete marker, purge, a key that never was). Tries: try-1792929068013610028 passed on 11a63579 (1010 unit, 1015 integration). Reviewed-by: reviewer-r6m@shanks at 11a635796df96f63418af81bf2ce5fef877b3949 Pushed-by: lead-47@shanks

mesh-tools added 2 commits 2026-10-25 11:54:07 +00:00

Apply the revision of a composition key whose digest the want names, from the revisions the bucket keeps (issue 1945) 8343c4fb36

Bound a key's history read to 10 s and test it on a real bus; the witness test waits for its process to run from its image (issue 1945)

mesh/delivery merged: source.main moved to novox/mesh-host@57b553ac5a57

Details

mesh/check pass 11a635796df9 on 57b553ac5a57 | unit 299 run, 1043 kept, 5 skipped | integration 302 run, 1045 kept, 4 skipped | over bound: unit (slow…

11a635796d

mesh-tools commented

2026-10-25 11:54:11 +00:00

Delivery novox/mesh-host@11a635796df9 — merged since 2026-10-25T12:30:42Z

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

Transitions

2026-10-25 11:54 (new) → proposed (announced): novox/mesh-host#139's head announced
2026-10-25 11:55 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 12:30 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-host@11a635796df9` — **merged** since 2026-10-25T12:30:42Z **Source** — source.main moved to novox/mesh-host@57b553ac5a57. Whether it reached the machines is `mesh-delivery-view`'s, derived from `source.main`, the wants and the haves. **Transitions** - 2026-10-25 11:54 (new) → proposed (announced): novox/mesh-host#139's head announced - 2026-10-25 11:55 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 12:30 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 57b553ac5a into main

2026-10-25 12:30:41 +00:00

mesh-tools deleted branch fix/r6-want-names-revision

2026-10-25 12:30:41 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-host#139