A built module keeps its build edges: a new SDK plans the toolchain and its TypeScript bundles (hq issue 614) #296
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: novox/mesh-controller#296
Reference in New Issue
Block a user
What: inventory.Dependencies now draws two edges it lost once a module was built (catalogue.Resolve registers every built manifest with Build = nil):
againstholds@novox/mesh-sdk@0.1.13(the builder's name@version for a package artifact). It is read as a stands-on edge to the module whose held artifact is that package, whichever version it holds now (Held). mesh-tools -> mesh-sdk.Bundlesthe resolved manifest keeps (language), as issue 211 drew it frombuild.artifactsbefore the first build. minio, umami, ... -> mesh-tools; Go bundles -> mesh-tools-go.Why this way, not keeping
buildon the entry or changing what the builder records: it reads only records the mesh already keeps. So it holds for every module already built, with no rebuild, no migration and no new builder on the build agents. A rollback to main reads the same records and simply loses the two edges again: nothing is written in a new shape. The other choices would need every module rebuilt before the edge exists, and the SDK would still plan nothing until then.Why: issue 614. mesh-sdk #24 (0.1.14) planned "builds mesh-sdk, sent nowhere", so issue 272's fix reached no provider. This is a regression of issues 211 and 212 once modules were built.
Tests:
delivery-plandoes (theGraph + pullScope over registered modules and recorded builds). On main it plans mesh-sdk, the live answer of 2026-10-13. With the fix it plans mesh-sdk] [mesh-tools] [minio umami. Uses only what main had, so it is the replay; registered in mesh-lab as R614.Note: a mesh-tools-go change now rebuilds every Go bundle, as issue 211 intended.
Fixes issue 614.
Delivery
novox/mesh-controller@e658a14296f9— delivered since 2026-10-13T09:42:17ZDelivery plan — builds build-agent, mesh-controller → ace, g14, novox, shanks; no bus step
Machines
Transitions
The commit's note under
refs/notes/mesh-plankeeps every transition:git log --notes=mesh-plan.Merge check at
e658a142Judged: head
e658a14296f9merged into trunk1826b68a22b5; read beside it: mesh-catalogf35b06750452, mesh-controller-main1826b68a22b5, mesh-host7a41e120635b, mesh-tools954e1a53eef9mesh/merge-gate: PASS — every machine composes with the change as it did without (4 of 4 compose) (modules: build-agent, mesh-controller)mesh/repo-check: PASS — its merge-check.sh passedDelivery plan — builds build-agent, mesh-controller → ace, g14, novox, shanks; no bus step
Run by the build seat on ace as
build-1791882523823626544(builds --log build-1791882523823626544).Verdict: approve at
e658a14296Independent review for issue 614. The statuses at this head are: mesh/merge-gate success ("head
e658a14296merged into trunk1826b68a22— pass: builds build-agent, mesh-controller → ace, g14, novox, shanks; no bus step; every …"), mesh/repo-check success ("heade658a14296merged into trunk1826b68a22— pass: its merge-check.sh passed") and mesh/delivery success ("ready: it delivers once merged").What I ran on g14, in a fresh HTTPS clone with a throwaway postgres 18 store: gofmt is clean and
go vet ./...passes.go test -racepasses for internal/inventory (85 s) and for the whole of cmd/mesh-controller (637 s), including TestATierPutsABrokenModuleBackAtOnce, which the description says is flaky on main. The store test TestReplay614ANewSDKPlansTheToolchainAndThenItsBundles passes, and it is listed in testdata/store-tests.The tests fail on main. With the two test files laid over origin/main, internal/inventory does not compile (dependenciesWith and packageName are undefined). The replay fails with "a new SDK plans mesh-sdk, want mesh-sdk] [mesh-tools] [minio umami", which is the live answer of 2026-10-13.
Correctness of the package match. packageName strips only the last "@version" and returns "" for artifact-store references, image digests, URLs and a scoped name with no version. The lookup is then an exact map lookup on the name, so "@novox/mesh-sdk-extra@1" cannot match mesh-sdk; there is no prefix match anywhere. The version is ignored on purpose, so a build that stood on 0.1.13 still reaches the module that now holds 0.1.14. That is the right choice. I checked the live record: mesh-tools' build build-1791808123247620326 of 2026-10-12 was handed MESH_SDK=@novox/mesh-sdk@0.1.13, which is exactly the shape this reads.
A stored build record without these fields. A build with no built_against is skipped by BuiltAgainst, and dependenciesOf passes a nil held map, so nothing panics and no edge is invented. A registered manifest whose bundles carry no language (bundle language has been kept since
b1df688of 2026-10-02) makes ToolchainFor return an error, and that bundle silently gets no toolchain edge. This is the same behaviour as before the fix and is not a blocker; it only matters for a module not rebuilt since 2026-10-02.Rollback to main. Nothing is written in a new shape: no migration, no new edge kind, no new field in the build record or the registered manifest. A controller rolled back reads the same rows and simply loses these two edges again.
A mesh-tools-go change now rebuilds every Go bundle. That is what issue 211 intended: its diagnosis tested "Go bundle → mesh-tools-go", and the code comment from that fix says that a toolchain that moves rebuilds every bundle compiled in it. ADR 0162 clauses 3 and 5 agree: a build dependency rebuilds the dependent in the next tier. The planner bounds it in order but not in size. tiersOf places mesh-tools-go first and every Go-bundle module after it. The built-by edge from mesh-tools-go to build-agent is skipped through isBaseOf, so no false cycle appears, and hasCycle would report one if it did. There is no cap on a tier's width. By mesh-catalog main, about 70 modules have a Go bundle, including mesh-controller and the core seats, so a mesh-tools-go merge becomes one wide walk. Rebuilds whose binaries come out identical are reported unchanged (issue 611), so only a compiler or flag change moves them. I recommend saying this in the record, but it does not block the merge.
Minor, not blocking. packagesHeld keys by package name, so if two modules ever held the same package name, the winner would depend on map order. Today only mesh-sdk holds a package.