A record a module once left in the node's composition goes with that module, so the node's own apply is no longer refused (issue 774) #186

Merged
mesh-tools merged 1 commits from fix/folded-record-goes-with-its-module into main 2026-10-31 00:21:40 +00:00
Member

Issue 774 (L3). Since 2026-10-30 19:42 novox's node's own apply has been refused every ~2 min: "the apply of node would remove restic.measure of restic, of modules a want still places here ... so nothing was applied" (0 resources of the node's own composition applied since). mesh-catalog 35ff67bd replaced restic's process measure with awake; restic.measure was recorded as the node's (from when restic's resources were in the node's own composition), restic's apply never owned it, and the guard of a7acee3/81672b1 refused the whole node apply forever. Now (1) the node's own apply keeps and logs a node-owned record whose id names a module with its own composition here, never refusing or removing it; (2) a module's own apply owns a node record whose id names it, and removes it once neither composition declares it (Others always holds the node's own). restic.measure goes at restic's next own apply.

Quick vs thorough: the quick fix (forget the record by hand) is a hand edit of the node's store and is not done; this is the thorough fix for every module whose resources once lived in the node's composition. Row "restic.measure" in the module_scope_test table fails on main with the live line. gofmt, vet (both tags), go test pass.

Reviewed-by: rev-held@shanks at 1d8d726758

Issue 774 (L3). Since 2026-10-30 19:42 novox's node's own apply has been refused every ~2 min: "the apply of node would remove restic.measure of restic, of modules a want still places here ... so nothing was applied" (0 resources of the node's own composition applied since). mesh-catalog 35ff67bd replaced restic's process measure with awake; restic.measure was recorded as the node's (from when restic's resources were in the node's own composition), restic's apply never owned it, and the guard of a7acee3/81672b1 refused the whole node apply forever. Now (1) the node's own apply keeps and logs a node-owned record whose id names a module with its own composition here, never refusing or removing it; (2) a module's own apply owns a node record whose id names it, and removes it once neither composition declares it (Others always holds the node's own). restic.measure goes at restic's next own apply. Quick vs thorough: the quick fix (forget the record by hand) is a hand edit of the node's store and is not done; this is the thorough fix for every module whose resources once lived in the node's composition. Row "restic.measure" in the module_scope_test table fails on main with the live line. gofmt, vet (both tags), go test pass. Reviewed-by: rev-held@shanks at 1d8d7267584e83fd6740cf02c0dd01cdbf9ea157
mesh-tools added 1 commit 2026-10-31 00:15:41 +00:00
Leave a record the node's own carried for a module that composes its own, and let that module's apply remove it, so the node's own is not refused for ever (issue 774)
mesh/delivery merged: source.main moved to novox/mesh-host@62b211bb6040
mesh/check checking 1d8d7267584e on 62b211bb6040
1d8d726758
On the bus node restic's manifest replaced its process measure by awake (mesh-catalog 35ff67bd). The record of restic.measure was the node's, made while restic was folded, so restic's own apply never saw it, and the guard against removing a placed module's resources refused the node's own apply whole every two minutes from 2026-10-30 19:42: nothing of the node's own applied.

Quick fix considered: forget the one record by hand (a hand act on the node; refused). Thorough fix (this): the node's own apply keeps such a record and says so, never refusing or removing it; a module's own apply owns a node record whose id names it, so it alone removes it once neither composition declares it.
Author
Member

Delivery novox/mesh-host@1d8d7267584e — merged since 2026-10-31T00:21:41Z

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

Transitions

  • 2026-10-31 00:15 (new) → proposed (announced): novox/mesh-host#186's head announced
  • 2026-10-31 00:15 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-31 00:21 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-host@1d8d7267584e` — **merged** since 2026-10-31T00:21:41Z **Source** — source.main moved to novox/mesh-host@62b211bb6040. Whether it reached the machines is `mesh-delivery-view`'s, derived from `source.main`, the wants and the haves. **Transitions** - 2026-10-31 00:15 (new) → proposed (announced): novox/mesh-host#186's head announced - 2026-10-31 00:15 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-31 00:21 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 62b211bb60 into main 2026-10-31 00:21:40 +00:00
mesh-tools deleted branch fix/folded-record-goes-with-its-module 2026-10-31 00:21:41 +00:00
Sign in to join this conversation.
No Reviewers
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: novox/mesh-host#186