jschoubben
4279e4914b
One green fresh run of the no-fake two-node bed is the proof: node2's consumers open the store and broker the mesh built and adopted, over the overlay. Fixed by mesh-controller PR 29, mesh-catalog PR 26, gated by mesh-lab PR 34.
2.5 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | |
|---|---|---|---|---|---|
| resolved | 2026-09-18 |
|
mesh-catalog PR 26 (1891b09); gated by mesh-lab PR 34 |
061 — A module container that names no command runs the wrong thing
Symptom
The broker module's provisioner never ran — anywhere, ever. Its runtime container declared no command, so it ran its image's default entrypoint, which is the tool host. The container came up, served its tools, logged its audit line, and reported healthy. The provisioner entrypoint compiled into the same image was never named by anything, so no consumer was ever granted its vhost and user.
Observed on the built-store-cross-node bed (2026-09-17): a consumer on the joined node held a correct binding, its grant sat applied in the provisioner's mounted grants directory, and the broker's vhost list never grew past the default. Every check between the consumer and the missing mint passed — the grant was composed, delivered, written; the container it fed was running and healthy. The bed's vhost assertion was the first thing in the mesh that could notice, and this bed is the first to reach it without pre-stocked images.
The defect was present from the module's first commit. It survived conversion, adoption of the foundation's broker, and every earlier bed, because none of them asserted the provision itself.
Why it matters beyond the instance
The manifest treats a container's command as optional, and the image's default entrypoint makes the omission plausible: the container runs, logs, and stays up. A module can therefore declare a provisioner-shaped container that provisions nothing, and nothing in validation, build, install, or health says so. Every module whose runtime image carries more than one entrypoint has this trap — the sibling module of the same shape names its provisioner explicitly, and only that habit separated the working provider from the silent one.
This is the constitution's central failure class — reports success and does nothing — expressed in one missing manifest field.
Open questions
- Should a manifest be able to omit a container's command at all when the module also declares
grants(i.e. claims to be a provider)? A provider whose containers all default their command provably runs no provisioner. - Can validation know an image's entrypoints, so "compiled but never named by any container" is refusable at build time rather than discoverable only by an end-to-end bed?
- Does any other converted module in the catalogue have the same shape today?