jschoubben
61f61b5d06
An audit of the six code repositories found eleven open issues fixed on main with commits and beds to show (025, 027, 033, 036, 037, 040, 045, 047, 050, 052, 053), three partly (007, 026, 035), nine not (020, 031, 041, 046, 049, 054, 064, 065, 066) and one whose fix would live outside those repos (006). Resolved ones name their evidence; partly ones say what remains; 041 records that the exposure has widened since it was reported.
3.0 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design |
|---|---|---|---|---|
| resolved | 2026-09-13 | mesh-host e7f94e0 (restart-on digests folded into the container spec, a standing comparison); unit-tested in apply_test.go, no lab assertion yet |
045 — A container keeps the values it started with
Symptom
A module reads its database credentials from a file the mesh composes. The file was written, then rewritten with a different value once the mesh had more to say — the provider's address was not known the first time and was the second.
The container went on running with the first version, indefinitely, and reported nothing. Its own view:
DATABASE_URL=postgresql://…@:20000/… what the container holds
DATABASE_URL=postgresql://…@<provider>:20000/… what the file on disk says
A module may declare that it restarts when one of its files changes, and this one now does. That did not help: the restart fires when the file changes during an apply, and the change had already happened before the declaration naming it arrived. Applying again is a no-op, because nothing changed that time either. The only thing that recovered it was removing the module from the machine and putting it back.
Why this matters
Reconciliation compares intentions, not what is actually running. Two intentions in a row can both be applied successfully and still leave a container holding values from neither, because a container captures its environment once, when it is created, and nothing afterwards re-reads it.
The failure is silent in the worst way: the container is up, the machine reports success, the mesh reports every module current, and the thing inside is using a credential the mesh no longer believes in. Nothing in the system is in a position to notice — the host knows what it wrote, and the module knows what it read, and no one compares the two.
It is not specific to credentials. Any composed value delivered through a file a container reads at start has the same shape, which is most of what the mesh delivers.
How it would be checked
A machine reporting a module as running should be able to say what it is running with — not what was last written for it. The check is then a comparison the mesh can make on every heartbeat rather than a property of one apply: for each container, does what it holds match what the files it was built from now say. A mismatch is a drift the mesh can act on, and today it is not expressible at all.
Open questions
- Should the host recreate such a container on its own, or report the drift and let the mesh decide? Recreating is the obvious repair and is also an unannounced restart of a running service.
- Is "the files a container was created from" something the host already knows, or does a declaration have to say it? A restart-on list is close to this, but it is written by the module author and is therefore exactly as complete as they remembered to make it.
- Does the same gap exist for values the mesh delivers by other means than a file?