Merge pull request 'Issue 211: a bundle is built before the toolchain it is compiled in; ADR 0192 progressive insight; design 38 WP4b built, WP4c opened' (#322) from issues/211-and-0192-insight into main
This commit was merged in pull request #322.
This commit is contained in:
+13
@@ -30,6 +30,19 @@ runtime calls without one, so every bundle reads the process's four words.
|
|||||||
Without a rule, each of the thirty-one would answer the question its own way, and the runtime's
|
Without a rule, each of the thirty-one would answer the question its own way, and the runtime's
|
||||||
process would be the one place where every module's paths meet.
|
process would be the one place where every module's paths meet.
|
||||||
|
|
||||||
|
> **Progressive insight — 2026-10-03.** The context above calls the thirty-one remaining containers
|
||||||
|
> tool containers handed what a bundle cannot receive. Measured the same day while building this
|
||||||
|
> record: nine of them run only tools; three run a main of their own; twenty import, beside their
|
||||||
|
> tools, the module's own long-running code — event handlers that subscribe on the bus and
|
||||||
|
> provisioners that act on grants — under the module's own bus identity, and some reach their
|
||||||
|
> service by a container network name or need a package the image installed. That code is not a
|
||||||
|
> tool and is not this record's to move: under
|
||||||
|
> [ADR 0188](0188-a-modules-own-code-is-bundles-in-any-language-and-a-tools-bundle-speaks-mcp-to-the-runtime.md)
|
||||||
|
> §3 it is a `process` bundle, and how it is given its credential, its words and its reach is the
|
||||||
|
> open question of [design 38](../03-DESIGN/01-to-be/38-building-the-operators-machine.md) WP4c.
|
||||||
|
> Decision 4 applies to these containers' tools; the containers themselves go when their other
|
||||||
|
> code has moved. The decision and its options stand.
|
||||||
|
|
||||||
## Considered Options
|
## Considered Options
|
||||||
|
|
||||||
1. **The bundle declares its environment on its artifact, and the mesh composes it as a
|
1. **The bundle declares its environment on its artifact, and the mesh composes it as a
|
||||||
|
|||||||
@@ -245,6 +245,25 @@ credential gone. Last, the registration gate refuses the container shape for eve
|
|||||||
answer from the runtime on the machines that run it, `docker ps` shows no tool container on any of
|
answer from the runtime on the machines that run it, `docker ps` shows no tool container on any of
|
||||||
the four, and `status` is well.
|
the four, and `status` is well.
|
||||||
|
|
||||||
|
*Found 2026-10-03, building it:* of the thirty-one, nine run only tools, three a main of their own,
|
||||||
|
and twenty import the module's own event handlers and provisioners beside their tools (ADR 0192's
|
||||||
|
dated note). WP4b moves the tools-only nine; WP4c holds the rest. Two of the nine stay with WP4c as
|
||||||
|
well — one carries a run-once provisioning step in a second container, one reads an env-file and two
|
||||||
|
sockets — so seven move here. *Built 2026-10-03:* mesh-sdk #12 (`collectToolsEach`), mesh-tools #33
|
||||||
|
(each bundle its own environment), mesh-controller #236 and #237 (the words composed, made the
|
||||||
|
account's to read, and named files restarting the runtime), and the seven modules in one change.
|
||||||
|
Building it found issue [211](../../04-ISSUES/211-a-bundle-is-built-before-the-toolchain-it-is-compiled-in/00-report.md).
|
||||||
|
|
||||||
|
## WP4c — The module's own long-running code moves
|
||||||
|
|
||||||
|
*Not yet broken down.* Twenty-three containers carry code that is not a tool: event handlers,
|
||||||
|
provisioners, a step, a main. [ADR 0188](../../02-DECISIONS/0188-a-modules-own-code-is-bundles-in-any-language-and-a-tools-bundle-speaks-mcp-to-the-runtime.md)
|
||||||
|
§3 already says such code is a `process` bundle the host runs. What no record says yet is how that
|
||||||
|
process is given what its container was: the module's own bus credential and the subscriptions it
|
||||||
|
consumes with, the words its code reads at import, the packages the image installed (a database's
|
||||||
|
client), and the service it reaches by a container network name. That begins with a decision record,
|
||||||
|
after which the twenty-three move and the registration gate refuses the container shape for all.
|
||||||
|
|
||||||
## WP5 — The shell, on a server first
|
## WP5 — The shell, on a server first
|
||||||
|
|
||||||
*mesh-catalog #224, already written. Half a day to assign and prove.*
|
*mesh-catalog #224, already written. Half a day to assign and prove.*
|
||||||
|
|||||||
@@ -0,0 +1,47 @@
|
|||||||
|
---
|
||||||
|
status: located
|
||||||
|
opened: 2026-10-03
|
||||||
|
located-in:
|
||||||
|
- mesh-controller
|
||||||
|
fixed-by:
|
||||||
|
amended-design:
|
||||||
|
---
|
||||||
|
|
||||||
|
# 211 — A bundle is built in the same tier as the toolchain it is compiled in, against the old toolchain
|
||||||
|
|
||||||
|
## What was observed
|
||||||
|
|
||||||
|
2026-10-03, merging a runtime change that needed a new SDK release. The SDK was published first;
|
||||||
|
then the merge of the tools repository planned two tiers, and the first held both the toolchain
|
||||||
|
images and the runtime's own bundle:
|
||||||
|
|
||||||
|
```
|
||||||
|
> tier 0
|
||||||
|
mesh-tools asked
|
||||||
|
node-tools built from 8e30ea9f
|
||||||
|
```
|
||||||
|
|
||||||
|
The bundle was built while its toolchain image was still being built. A TypeScript bundle's
|
||||||
|
dependencies are copied from the toolchain image it is compiled in
|
||||||
|
([design 38](../../03-DESIGN/01-to-be/38-building-the-operators-machine.md) WP3), so this one was
|
||||||
|
compiled and packed against the toolchain as it stood before the merge — carrying the old SDK —
|
||||||
|
and was recorded as built from the new commit.
|
||||||
|
|
||||||
|
## Why it matters beyond this instance
|
||||||
|
|
||||||
|
Every bundle compiled by a toolchain depends on the module that publishes that toolchain, and the
|
||||||
|
planner does not know it: a manifest names its toolchain by `language`, not in `build.on`, so the
|
||||||
|
dependency is implicit and the tiers are computed without it. Whenever a change touches the
|
||||||
|
toolchain and a bundle in one merge — or the toolchain's own repository holds a bundle, as this one
|
||||||
|
does — the bundle is built against the previous toolchain and reported current. Nothing fails; the
|
||||||
|
bundle simply carries yesterday's dependencies under today's commit.
|
||||||
|
|
||||||
|
## Diagnosis
|
||||||
|
|
||||||
|
Owner mesh-controller: the planner orders a merge's modules by `build.on`; the builder's toolchain
|
||||||
|
for a bundle (`ToolchainFor(language)`: the module and artifact it is compiled in) is not part of
|
||||||
|
that order. **Fix direction:** the planner treats a bundle's toolchain as a `build.on` it did not
|
||||||
|
have to write — a bundle of language L depends on the module that publishes L's toolchain — so the
|
||||||
|
bundle lands in the tier after it. A test: a merge touching the toolchain module and a TypeScript
|
||||||
|
bundle plans the bundle one tier later. Worked around on the day by building the bundle again once
|
||||||
|
the toolchain was built.
|
||||||
Reference in New Issue
Block a user