jschoubben
778efaba8b
Issue 003 is answered in both halves: manifests are parsed strictly, and a module says what it listens on and from where rather than carrying a key nothing reads. The design records what was built and how each part is checked. Issue 013 is new, found by reading while writing the first module that has both a computed file and a service that needs it. The file arrived second. It failed, then the next reconcile fixed it, which is why nothing caught it.
2.7 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | |
|---|---|---|---|---|---|
| resolved | 2026-08-31 |
|
mesh-control — what the mesh computes is applied before what the module declared |
013 — A file the mesh computes arrives after the service that needs it
Symptom
Everything the control plane computes for a module — a certificate, a sealed credential, a bound file, a rule set — was placed after that module's own resources in the declaration. The host applies resources in the order it is given and does not sort, so a service or container declared in a manifest was applied before the file it depends on existed.
On the first apply the service starts against a missing file and fails. The next reconcile finds the file there and starts it.
Why this matters
It repairs itself, which is why nothing caught it. A fault that is gone by the second attempt is worse than one that persists: what gets remembered is that the thing works, and the failed first apply is read as a machine that was briefly slow. The mesh reports a failure, then reports success, and nobody looks again.
It was also invisible to every test that existed, because none of them combined the two halves. Modules with computed files declared no service; modules with a service needed no computed file. The fault lived exactly in the gap between two repositories' assumptions — the control plane deciding an order, the host promising not to change it — which is the shape this folder exists for.
Found by reading, while writing the first module that has both: a firewall whose service must reflect a rule set the mesh computes.
Evidence
internal/catalogue/declaration.go built each module's resource list as
append(module's own, computed...) in six places — certificate, authority, needs, secrets, grants,
bindings. internal/apply/apply.go iterates d.Resources in order, and
internal/declaration/declaration_test.go states the rule directly: order is stated, not derived.
The host must not sort.
What was done
The computed resources are assembled first and the module's own resources follow. Nothing the mesh computes is derived from a module's resources, so the order is unconditionally right rather than a heuristic — there is no case where a module's resource must precede a file the mesh made for it.
Merged after the computed-resources branch, which replaces a module's resources wholesale and would otherwise discard everything the mesh had made for it.
Checked by a module declaring a service that reflects a rule set, asserting the rule set is first; and by a module whose resources are computed elsewhere, asserting its credential survives and is still first — the case the merge point exists for.