1.9 KiB
Diagnosis — 2026-09-21
- The host's marker for a run-once step is the digest of its declaration, and that digest
already includes the digest of every resource the container names under
restart-on— what a container reads is part of what it is (issue 045). So a run-once step that named the binding file it reads would run again the moment the mesh rewrote that file. Only the refusal of the pair run-once +restart-on, in the manifest parser and on the host, stood in the way. - When the authority moves, the binding's address changes and the file is rewritten; a re-issue changes nothing the authority serves, since its state persists. The file is the signal.
- The service also had to follow: a step that ran counts as a change, so a service naming the
step under
restart-onis recreated with what the step fetched.
Located in: the two refusals and the proxy's manifest. Decided in ADR 0099; proven by unit tests on the host (the step runs again when its file changed, and not when it did not; the container naming the step is recreated after it ran) and the catalogue-wide manifest test.
What closed it, and what did not. The report named two ways the fact changes: the provider moved, or its state wiped. The move is closed: it rewrites the consumer's binding, the step names that binding, and the host's unit test runs the step again on exactly that rewrite — the bed that would re-key a live authority was not written, because a move is a rewritten file and the unit test covers the file. A state wiped behind the mesh's back on the same node is not closed and is not claimed (ADR 0099, consequences): nothing the mesh knows changes, so nothing it declares can follow it. On the mesh's own path it does not arise — the authority's state directory survives unassign and reassign, and a re-issue does not touch it.