Issue 1126 note 91; the operator asked for it at once. mesh-delivery.show and knowledge-base.progress said mesh-delivery#96 was 'not yet on the machines: mesh-delivery-view on shanks is applying …, not running' while node_haves said running and healthy. The delivery view marked its reach write (and its reached-head, delivered-revision and motion events) as done before the bus took it. At its own restart at 14:46Z the bus answered 'no responders', so the value stayed wrong, although the log said 'written again at its next change'.
Now every write and event the view makes returns its error, and the model forgets whatever was refused: the next change in a watched bucket writes or says it again. Event ids deduplicate a repeat. This is the second time today this line was wrong (the vault this morning).
Quick vs thorough: quick was forgetting only the refused reach write; thorough, chosen, covers all four places with the same fault. Reading node haves at answer time was weighed and not taken: the view stays the one writer show and progress read.
Notes kept (not wrong): a refused write in a fully quiet stretch waits for the next change (follow-up: write again on the bus reconnecting); a lost ack on a stored 'moving' could keep 'settled' unsaid; an older ordering race between bucket watches.
Tests: rows in existing tests (reach_test, wants_test), each failing with its forget step switched off; no new function (588 unit, over budget, not raised). go test -race passes.
Issue 1126 note 91; the operator asked for it at once. mesh-delivery.show and knowledge-base.progress said mesh-delivery#96 was 'not yet on the machines: mesh-delivery-view on shanks is applying …, not running' while node_haves said running and healthy. The delivery view marked its reach write (and its reached-head, delivered-revision and motion events) as done before the bus took it. At its own restart at 14:46Z the bus answered 'no responders', so the value stayed wrong, although the log said 'written again at its next change'.
Now every write and event the view makes returns its error, and the model forgets whatever was refused: the next change in a watched bucket writes or says it again. Event ids deduplicate a repeat. This is the second time today this line was wrong (the vault this morning).
Quick vs thorough: quick was forgetting only the refused reach write; thorough, chosen, covers all four places with the same fault. Reading node haves at answer time was weighed and not taken: the view stays the one writer show and progress read.
Notes kept (not wrong): a refused write in a fully quiet stretch waits for the next change (follow-up: write again on the bus reconnecting); a lost ack on a stored 'moving' could keep 'settled' unsaid; an older ordering race between bucket watches.
Tests: rows in existing tests (reach_test, wants_test), each failing with its forget step switched off; no new function (588 unit, over budget, not raised). go test -race passes.
Reviewed-by: rev-reach@shanks at 726bbf1f1ffa33672f7039d7b7befd39ccc64d0d
The view remembered a reach value, a reached head and a motion event as written or said before the bus took them; a write refused at its start (no responders) was never made again while the derivation stayed the same, and mesh-delivery.show said mesh-delivery-view not running on shanks while node_haves said it running.
Quick fix: forget only the refused reach write. Thorough fix, chosen: every write and event the view makes after its lock (reach, reached head, delivered revision, motion) answers its error, and the model forgets what was refused, so the next change it takes in makes it again; one place, the writer of the state both mesh-delivery.show and knowledge-base.progress read.
Deliverynovox/mesh-delivery@726bbf1f1ffa — merged since 2026-10-28T15:18:56Z
Source — source.main moved to novox/mesh-delivery@2ac146078f. Whether it reached the machines is mesh-delivery-view's, derived from source.main, the wants and the haves.
Transitions
2026-10-28 15:14 (new) → proposed (announced): novox/mesh-delivery#97's head announced
2026-10-28 15:14 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-28 15:18 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-delivery:view -->
**Delivery** `novox/mesh-delivery@726bbf1f1ffa` — **merged** since 2026-10-28T15:18:56Z
**Source** — source.main moved to novox/mesh-delivery@2ac146078f47. Whether it reached the machines is `mesh-delivery-view`'s, derived from `source.main`, the wants and the haves.
**Transitions**
- 2026-10-28 15:14 (new) → proposed (announced): novox/mesh-delivery#97's head announced
- 2026-10-28 15:14 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-28 15:18 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`.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Issue 1126 note 91; the operator asked for it at once. mesh-delivery.show and knowledge-base.progress said mesh-delivery#96 was 'not yet on the machines: mesh-delivery-view on shanks is applying …, not running' while node_haves said running and healthy. The delivery view marked its reach write (and its reached-head, delivered-revision and motion events) as done before the bus took it. At its own restart at 14:46Z the bus answered 'no responders', so the value stayed wrong, although the log said 'written again at its next change'.
Now every write and event the view makes returns its error, and the model forgets whatever was refused: the next change in a watched bucket writes or says it again. Event ids deduplicate a repeat. This is the second time today this line was wrong (the vault this morning).
Quick vs thorough: quick was forgetting only the refused reach write; thorough, chosen, covers all four places with the same fault. Reading node haves at answer time was weighed and not taken: the view stays the one writer show and progress read.
Notes kept (not wrong): a refused write in a fully quiet stretch waits for the next change (follow-up: write again on the bus reconnecting); a lost ack on a stored 'moving' could keep 'settled' unsaid; an older ordering race between bucket watches.
Tests: rows in existing tests (reach_test, wants_test), each failing with its forget step switched off; no new function (588 unit, over budget, not raised). go test -race passes.
Reviewed-by: rev-reach@shanks at
726bbf1f1fDelivery
novox/mesh-delivery@726bbf1f1ffa— merged since 2026-10-28T15:18:56ZSource — source.main moved to novox/mesh-delivery@2ac146078f. Whether it reached the machines is
mesh-delivery-view's, derived fromsource.main, the wants and the haves.Transitions
The commit's note under
refs/notes/mesh-plankeeps every transition of this change up to its merge:git log --notes=mesh-plan.