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.
50 lines
2.5 KiB
Markdown
50 lines
2.5 KiB
Markdown
---
|
|
status: resolved
|
|
opened: 2026-09-18
|
|
located-in:
|
|
- mesh-catalog
|
|
fixed-by: mesh-catalog PR 26 (1891b09); gated by mesh-lab PR 34
|
|
amended-design:
|
|
---
|
|
|
|
# 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?
|