From f8458d6f2ca4834a9676f99666a8da04232e9263 Mon Sep 17 00:00:00 2001 From: jochen Date: Sat, 3 Oct 2026 15:36:26 +0200 Subject: [PATCH] Issue 211: a bundle is built before the toolchain it is compiled in; ADR 0192 progressive insight; design 38 WP4b built, WP4c opened --- ...e-runtime-hands-it-to-that-bundle-alone.md | 13 +++++ .../38-building-the-operators-machine.md | 19 ++++++++ .../00-report.md | 47 +++++++++++++++++++ 3 files changed, 79 insertions(+) create mode 100644 04-ISSUES/211-a-bundle-is-built-before-the-toolchain-it-is-compiled-in/00-report.md diff --git a/02-DECISIONS/0192-a-tools-bundle-declares-what-it-is-given-and-the-runtime-hands-it-to-that-bundle-alone.md b/02-DECISIONS/0192-a-tools-bundle-declares-what-it-is-given-and-the-runtime-hands-it-to-that-bundle-alone.md index 516b723..6b7bcaf 100644 --- a/02-DECISIONS/0192-a-tools-bundle-declares-what-it-is-given-and-the-runtime-hands-it-to-that-bundle-alone.md +++ b/02-DECISIONS/0192-a-tools-bundle-declares-what-it-is-given-and-the-runtime-hands-it-to-that-bundle-alone.md @@ -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 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 1. **The bundle declares its environment on its artifact, and the mesh composes it as a diff --git a/03-DESIGN/01-to-be/38-building-the-operators-machine.md b/03-DESIGN/01-to-be/38-building-the-operators-machine.md index 21503ff..136b502 100644 --- a/03-DESIGN/01-to-be/38-building-the-operators-machine.md +++ b/03-DESIGN/01-to-be/38-building-the-operators-machine.md @@ -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 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 *mesh-catalog #224, already written. Half a day to assign and prove.* diff --git a/04-ISSUES/211-a-bundle-is-built-before-the-toolchain-it-is-compiled-in/00-report.md b/04-ISSUES/211-a-bundle-is-built-before-the-toolchain-it-is-compiled-in/00-report.md new file mode 100644 index 0000000..11e9ba4 --- /dev/null +++ b/04-ISSUES/211-a-bundle-is-built-before-the-toolchain-it-is-compiled-in/00-report.md @@ -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. -- 2.54.0