hq/04-ISSUES/077-a-fact-fetched-at-first-start-is-fetched-once/01-diagnosis.md

Diagnosis — 2026-09-21

1. 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.
2. 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.
3. The service also had to follow: a step that ran counts as a change, so a service naming the step under restart-on is 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.