2.0 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | ||
|---|---|---|---|---|---|---|
| located | 2026-10-03 |
|
212 — A toolchain rebuild keeps the SDK it cached, and every bundle built on it carries the old one
What was observed
2026-10-03, rolling out ADR 0193. SDK 0.1.5 was published, then the TypeScript toolchain image was rebuilt, then node-tools and six bundles were rebuilt on it and pushed. On every machine the bundles carried SDK 0.1.3:
bundle SDK: "version": "0.1.3"
The launched packet filter and intrusion prevention, which register their seat first, then served
their seat's verbs as their own tools, and node-packet-filter.* and node-intrusion-prevention.*
stopped answering on three machines until fixed.
Why it matters beyond this instance
The toolchain image installs its dependencies from a package.json that names the SDK by range.
The file did not change, so the image build reused its cached install layer, and "rebuilt after
the release" did not mean "carries the release". Every TypeScript bundle copies its dependencies
from that image (design 38 WP3),
so an SDK release reaches no bundle until something else happens to change that file. Nothing
reports it: the build succeeds and records the new commit.
Diagnosis
Owners mesh-tools (the image's recipe) and mesh-controller (the builder that runs it). Worked
around on the day by requiring ^0.1.5 in node-tools' package.json (mesh-tools #37), which
changes the layer. Fix direction: a toolchain build must not trust a cached dependency install —
install from a lockfile that a release updates, or build the install layer without the cache — and
the build should record which SDK version the image carries, so a bundle's record says what it was
compiled against. A check: after an SDK release and a toolchain rebuild, a bundle built on it reports
the released version.