Files
hq/04-ISSUES/061-a-module-container-that-names-no-command-runs-the-wrong-thing/01-diagnosis.md
jschoubben a0acaad86d Issues 061/062 — two silent-success defects the no-fake bed surfaced
061: the broker module's provisioner never ran; its runtime container
named no command and the image default is the tool host. 062: a failed
artifact-store lookup composed the network without the registry trust,
turning a transient error into permanent silent state. Both located,
fixes on the 042/048 train branches.
2026-09-18 00:23:52 +02:00

1.9 KiB

Diagnosis — 2026-09-17/18

The trail, from the failing assertion inward:

  1. The bed asserted no vhost existed for the joined node's consumer after four minutes of polling. The broker's management API listed only the default vhost.
  2. On the provider machine, the consumer's grant file was present in the provisioner's mounted grants directory, applied by the host minutes earlier — composition (including the re-push of the provider node, issue 057's remedy) and delivery were all correct.
  3. The provisioner container's log carried only the tool host's lines: the audit subscription and the tool listing. No provisioner harness line, no error. The provisioner was not failing — it was not running.
  4. The module's manifest declares two containers: the server (the adopted broker) and the runtime. The runtime names volumes and environment but no command. The image's default entrypoint is the tool host, so that is what ran.
  5. The sibling provider of the same shape (the database module) names its provisioner explicitly in its runtime container's command — the pattern the broker module was meant to follow. Its own image documentation says the provisioner "runs separately", named by the declaration; the declaration never did.
  6. History: the command was absent from the module's first commit. No regression — a hole.

Located in: mesh-catalog (the broker module's manifest). The fix names the provisioner entrypoint as the runtime container's command, mirroring the database module. Verified on the same bed: with the command named, the vhost and user are minted and the consumer holds its connection over the overlay (bed run of 2026-09-18).

The open questions in the report — refusing a provider whose containers all default their command, and auditing the rest of the catalogue for the same shape — remain open; this record covers the one module the bed proved.