Compose a module held as what runs of it with the tools it serves as it runs, and judge a data move by its data items (issue 1126) #130

2026-10-29T07:48:41Z

mesh-tools commented

2026-10-29 07:48:41 +00:00

Why

After placement's take-over on 2026-10-29, shanks's runtime stopped serving the folded systemd-resolved (the node-resolver seat's verbs answered "nothing serves"), and novox's runtime stopped serving the folded nats. Each runs inside its node's own composition at a build of the old form, and is composed as what runs of it from the catalogue's manifest, which no build resolved and so has no bundles. The runtime's tool list is made from bundles, so those modules were dropped. A held module with a new build had the opposite fault: it handed bundles that were never delivered.

On novox, mongodb and mssql asked the operator to approve a move of their data on a toolchain move. The running side, read back from the kept declaration, carried no data flag, and the judgement returned moves-data on the flag before it compared the data places. So a flag mismatch both raised a false ask and could hide a real move.

What changes

compose.ToolsRunning reads what the node's runtime serves as it runs: its process's tool modules and environment, and each bundle archive at its module's bundle path. A bundle the runtime loads nothing of takes its loads and words from the module's build (catalogue.BundleLoads, now one function). Every module stubbed in the machine's runtime, held or carried, contributes those bundles, whatever its manifest says. The runtime process and each archive are matched by their owning module too.
delivery.JudgeMove returns moves-data only when a data item changes (a directory or file within the data places, or a process of a module with data). A difference in the flag alone is neither, and its words say so with a WARNING.

Quick fix or thorough fix

The quick fix: read the old-form build's resolved manifest for a folded module. That covers one instance, and a held module would still hand its new bundles.
The thorough fix, chosen: every module composed as what runs of it (stubbed, carried, held or folded at an old build) contributes the tools that run, read from the runtime, so the kind is closed for all of them. The data judgement is fixed where every caller reads it (mesh-sdk delivery). mesh-host also stops building a running composition without Data (mesh-host, the other member of this group).

How it is checked

TestCompositionsAreTheDeclarationSplitByModule has rows for a folded module, a held module and a runtime that already dropped a module's tools. TestJudgeMove has one row changed and one added (a flag-only difference). No new test function.
Live: after the delivery, shanks/node-resolver.* and novox's nats tools answer again. A toolchain move of novox's mongodb or mssql raises no "moves data" ask (operator-channel.asks).

Group: delivery group fix/1126-924-held-and-judged, with mesh-host, which pins this head. (Re-opened from #129 under the group's shared branch name; the commits are unchanged.)

Reviewed-by: rev-held2@shanks at 575cb82fba
Reviewed-by: rev-held3@shanks at 575cb82fba

## Why After placement's take-over on 2026-10-29, shanks's runtime stopped serving the folded systemd-resolved (the node-resolver seat's verbs answered "nothing serves"), and novox's runtime stopped serving the folded nats. Each runs inside its node's own composition at a build of the old form, and is composed as what runs of it from the catalogue's manifest, which no build resolved and so has no bundles. The runtime's tool list is made from bundles, so those modules were dropped. A held module with a new build had the opposite fault: it handed bundles that were never delivered. On novox, mongodb and mssql asked the operator to approve a move of their data on a toolchain move. The running side, read back from the kept declaration, carried no data flag, and the judgement returned moves-data on the flag before it compared the data places. So a flag mismatch both raised a false ask and could hide a real move. ## What changes - `compose.ToolsRunning` reads what the node's runtime serves as it runs: its process's tool modules and environment, and each bundle archive at its module's bundle path. A bundle the runtime loads nothing of takes its loads and words from the module's build (`catalogue.BundleLoads`, now one function). Every module stubbed in the machine's runtime, held or carried, contributes those bundles, whatever its manifest says. The runtime process and each archive are matched by their owning module too. - `delivery.JudgeMove` returns moves-data only when a data item changes (a directory or file within the data places, or a process of a module with data). A difference in the flag alone is neither, and its words say so with a WARNING. ## Quick fix or thorough fix - The quick fix: read the old-form build's resolved manifest for a folded module. That covers one instance, and a held module would still hand its new bundles. - The thorough fix, chosen: every module composed as what runs of it (stubbed, carried, held or folded at an old build) contributes the tools that run, read from the runtime, so the kind is closed for all of them. The data judgement is fixed where every caller reads it (mesh-sdk `delivery`). mesh-host also stops building a running composition without Data (mesh-host, the other member of this group). ## How it is checked - `TestCompositionsAreTheDeclarationSplitByModule` has rows for a folded module, a held module and a runtime that already dropped a module's tools. `TestJudgeMove` has one row changed and one added (a flag-only difference). No new test function. - Live: after the delivery, `shanks/node-resolver.*` and novox's nats tools answer again. A toolchain move of novox's mongodb or mssql raises no "moves data" ask (`operator-channel.asks`). Group: delivery group fix/1126-924-held-and-judged, with mesh-host, which pins this head. (Re-opened from #129 under the group's shared branch name; the commits are unchanged.) Reviewed-by: rev-held2@shanks at 575cb82fba692865a147f29649948f72e30151b6 Reviewed-by: rev-held3@shanks at 575cb82fba692865a147f29649948f72e30151b6

mesh-tools added 3 commits 2026-10-29 07:48:42 +00:00

A module composed as what runs of it serves its tools as they run, so the runtime no longer drops it (issue 1126) f50e004e8d

After the take-over of placement on 2026-10-29, shanks's runtime stopped serving the folded systemd-resolved (the
node-resolver seat's verbs answer "nothing serves") and novox's the folded nats. Neither has a want: each runs inside
its node's own composition at a build of the old form (Scope.InOwn), and is composed as Carried of the indexer's
manifest. That manifest is the catalogue's, which no build resolved, so it has no bundles (catalogue/build.go: Bundles
are set only by a build's resolution), and the runtime's MESH_TOOL_MODULES and MESH_TOOL_ENV are made from bundles
(catalogue/runtime.go). The controller composed them from the resolved manifest its store kept.

The kind: a module composed as what runs of it (Stub, Carried: held, or folded at an old build) contributes to the
others from its manifest, not from what runs. For a held module with a new build it is the other way round: its new
bundles are served, which were never delivered.

- The quick fix: read the old-form build's resolved manifest for a folded module. One instance; a held module still
hands its new bundles.
- The thorough fix, chosen: compose.ToolsRunning reads what the node's runtime serves as it runs (its process's
MESH_TOOL_MODULES and MESH_TOOL_ENV, each bundle's archive), frombus gives it as Node.RunsTools, and every stubbed
module of the machine's runtime (held or carried) contributes those bundles, whatever its manifest says.

Tests: two rows (folded, held) added to TestCompositionsAreTheDeclarationSplitByModule; no new test function.

A data flag that differs alone moves no data: the judgement reads the data items first, and says the flag loudly (issue 1126) b6768dad25

novox's mongodb and mssql asked a yes for moving their data on a toolchain move: the running side, read back from the
kept declaration, carries no data flag, and judge.go returned moves-data on the flag before it compared the data
directories and files, so a flag mismatch both raised a false ask and hid a real move. Now moves-data only when a
data item (a directory or file within the data places, or a process of a module with data) changes; a flag-only
difference is neither, with a WARNING in its words. One row changed and one added in TestJudgeMove.

A runtime that already dropped a carried module's tools serves them again, read from what runs and its build (issue 1126, review)

mesh/delivery-group group fix/1126-924-held-and-judged rejected: composed together: the checker's verdict at the members' heads (7e4e345e9969): mesh-build-go

Details

mesh/delivery closed: the pull request closed unmerged

Details

mesh/check checking 575cb82fba69 on 394fec8a63c1 | novox/mesh-sdk#130 in group fix/1126-924-held-and-judged

575cb82fba

rev-held2: ToolsRunning took a carried module's bundles from the runtime's MESH_TOOL_MODULES alone, and shanks had
already applied the drop of systemd-resolved, so its runs stayed empty and the drop permanent. Now every bundle
archive that runs at its module's BundlePath is a running bundle; one the runtime loads nothing of takes its loads and
words from the module's build (its built bundles, else its build's artifacts, by catalogue.BundleLoads, the rule a
build's resolution keeps, now one function). The runtime process and each archive are matched by their owning module
too, not only by id and path. A row added: the runtime already dropped it.

mesh-tools commented

2026-10-29 07:48:45 +00:00

Delivery novox/mesh-sdk@575cb82fba69 — closed since 2026-10-29T08:42:51Z

Transitions

2026-10-29 07:48 (new) → proposed (announced): novox/mesh-sdk#130's head announced; #129 with the same head closed unmerged
2026-10-29 07:48 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-29 08:42 ready → closed (closed): the pull request closed unmerged

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-sdk@575cb82fba69` — **closed** since 2026-10-29T08:42:51Z **Transitions** - 2026-10-29 07:48 (new) → proposed (announced): novox/mesh-sdk#130's head announced; #129 with the same head closed unmerged - 2026-10-29 07:48 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-29 08:42 ready → closed (closed): the pull request closed unmerged 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 closed this pull request

2026-10-29 08:42:50 +00:00

mesh-tools commented

2026-10-29 08:42:51 +00:00

mesh-delivery: the operator's Approve of this pull request's merge into main is ended: its head c7476aae09ff is no longer the pull request's head, or the pull request closed. Nothing is merged on it. The operator is asked again once the checks pass at the new head.

Pull request closed

Please reopen this pull request to perform a merge.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-sdk#130