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)

Conversation 1 Commits 3 Files Changed 7

+257 -22

3 Commits

Author	SHA1	Message	Date
jschoubben	575cb82fba	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 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.	2026-10-29 01:37:47 +01:00
jschoubben	b6768dad25	A data flag that differs alone moves no data: the judgement reads the data items first, and says the flag loudly (issue 1126) 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.	2026-10-29 01:36:17 +01:00
jschoubben	f50e004e8d	A module composed as what runs of it serves its tools as they run, so the runtime no longer drops it (issue 1126) 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.	2026-10-29 01:30:50 +01:00

Author

SHA1

Message

Date

jschoubben

575cb82fba

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

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.

2026-10-29 01:37:47 +01:00

jschoubben

b6768dad25

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

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.

2026-10-29 01:36:17 +01:00

jschoubben

f50e004e8d

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

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.

2026-10-29 01:30:50 +01:00

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) #129