ADR 0099: a step that runs once names what it reads; issues 077 and 078 resolved; designs 08 and 20 amended

2026-09-21 23:33:47 +02:00
parent c2a81cbb20
commit 0e0f0298c6
8 changed files with 146 additions and 7 deletions
@@ -1,7 +1,9 @@
 ---
-status: open
+status: resolved
 opened: 2026-09-21
-located-in: [mesh-host internal/apply (run-once marker), mesh-catalog modules/route-proxy]
+located-in: [mesh-host internal/declaration, mesh-controller internal/catalogue, mesh-catalog modules/route-proxy]
+fixed-by: ADR 0099; mesh-host and mesh-controller multiple-fixes (a run-once step may name what it reads and runs again when it changed); mesh-catalog multiple-fixes (the proxy's gate names the binding, the server names the gate)
+amended-design: 03-DESIGN/01-to-be/08-connectivity.md, 03-DESIGN/01-to-be/20-writing-a-module.md
 ---

 # 077 — A fact fetched at first start is fetched once per declaration
@@ -0,0 +1,16 @@
+# 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](../../02-DECISIONS/0099-a-step-that-runs-once-names-what-it-reads.md); 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.
@@ -1,7 +1,8 @@
 ---
-status: open
+status: resolved
 opened: 2026-09-21
-located-in: [mesh-controller internal/inventory (secrets), mesh-controller cmd (secret accept)]
+located-in: [mesh-controller internal/inventory (secrets)]
+fixed-by: mesh-controller multiple-fixes (a delivery is refused for a name the module does not declare as an own secret, a requirement it has not got, or a local it does not keep; the refusal names what it does declare); found one stale delivery in the whole-mesh bed on the spot
 ---

 # 078 — A delivered secret is accepted under any name
@@ -0,0 +1,17 @@
+# Diagnosis — 2026-09-21
+
+1. Acceptance sealed the value and wrote the row without reading the module's manifest, which the
+   mesh holds. Both delivery paths did: a module's own secret, and a pair credential for a
+   requirement kept in the vault.
+2. Refused now, in the inventory, so every caller gets it: an own secret must be one the manifest
+   declares; a pair credential must name a requirement the module has, and where the module keeps
+   several secrets for it (ADR 0094) a local it keeps — and no local where it keeps one. Each
+   refusal names what the module does declare.
+3. The refusal found a stale delivery at once: the whole-mesh bed delivered `smtp-pass` to a module
+   that declares `smtp-password`. Corrected in the bed.
+
+**Located in:** the inventory's two accept paths. Not a decision: the manifest was already the
+authority on what a module holds. Proven by unit tests against the store: a delivery under an
+undeclared name is refused naming the declared ones; under a declared name it is kept; to an
+unknown module it is refused with the remedy; a pair delivery for a requirement the module has not
+got, or with no local where several are kept, or under a local it does not keep, is refused.