jochen
daa9f171ae
The import of slice 3 (ADR 0275) was checked against every folder: no report changed since the commit it read, and the tracker holds each report's status, owner, fix, design amendment, replay and closing day. The keys are removed from all 361 reports, cycle.py refuses them in any report, and the playbooks, skills and READMEs that still pointed at them name the tracker instead.
2.8 KiB
opened
| opened |
|---|
| 2026-09-13 |
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?