Issue 211: a bundle is built before the toolchain it is compiled in; ADR 0192 progressive insight; design 38 WP4b built, WP4c opened

2026-10-03 15:36:26 +02:00
parent c5778f4366
commit f8458d6f2c
3 changed files with 79 additions and 0 deletions
@@ -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.