Merge pull request 'Issue 195: located in the controller's user composition' (#370) from issue/195-diagnosis into main

2026-10-04 15:34:11 +00:00
parent 02b4ca9bec 7cd5b37afe
commit dd8b15a0df
2 changed files with 46 additions and 2 deletions
@@ -1,7 +1,7 @@
 ---
-status: open
+status: located
 opened: 2026-10-02
-located-in: []
+located-in: [mesh-controller]
 fixed-by:
 amended-design:
 ---
@@ -0,0 +1,44 @@
+# 195 — Diagnosis
+
+## 2026-10-04
+
+**The count had grown, and was still almost all noise.** Every push now opens with 137 users the mesh
+"has minted no credential for", across four machines. Checked against the catalogue: six modules declare
+an own secret named `broker`; every other module declares none.
+
+**Where the line comes from.** The controller composes the bus's user list from its records: one user
+for the controller, one per machine, one per live enrolment token, one per person — and one per module
+assigned to a machine, whatever the module declares. Users with no minted credential are left out of the
+written file and named in the line. A module with no `broker` secret can never be minted one: issuing
+refuses it, because an account nothing reads is an orphan ([issue 078](../078-a-delivered-secret-is-accepted-under-any-name/00-report.md)).
+So for those modules the user was composed only to be left out and reported, on every status, plan and
+push.
+
+**Why that is safe to stop.** Where the machine's tool runtime runs — every machine, now — the runtime
+is the module's way onto the bus ([ADR 0175](../../02-DECISIONS/0175-one-tool-runtime-per-node-serves-every-modules-tools-on-the-host-side.md),
+[ADR 0198](../../02-DECISIONS/0198-a-modules-long-running-code-is-launched-by-the-node-runtime-and-reaches-the-bus-through-it.md)); its grants are the union of
+what the modules it carries declare, and that is unchanged. Where no runtime runs, a module without a
+`broker` secret cannot connect at all, and a user would not change that.
+
+**What else read the module users.** Each module's durable consumer was derived from its own user. A
+module carried by the runtime and declaring no `broker` secret would have lost its consumer, and the
+runtime reads that consumer on the module's behalf (ADR 0198). The consumers are now derived from the
+module users and from what each runtime carries, one per module and machine.
+
+**Ruled out as still open.** The report's first real gap — a declared `broker` secret filled with a
+generated value — was closed by [issue 203](../203-a-fresh-assignment-is-pushed-before-its-credential-exists/00-report.md): a push refuses to make one and names the verb that issues
+it. The second — a module that emits with no way onto the bus — has no case on a machine where the
+runtime runs, which is every machine now.
+
+**Fix.** A module user is composed only for a module declaring an own secret named `broker`; the
+consumers are derived as above. The written accounts file is unchanged, since the users dropped never
+had a password. What the line names from now on is the real gap: a module that can read an account and
+has not been issued one. Checked by the broker package's tests: no user for a module without an
+account, and its consumer still made.
+
+## Answers to the report's questions
+
+- *Should a bus user be composed for a module that declares no `broker` secret?* No.
+- *Is a `broker` secret ever correctly made by the generic generator?* No; issue 203 already refuses it.
+- *Should a module that speaks on the bus be refused when it declares no `broker` secret?* Not while the
+  runtime carries it; left for a machine without one, where no case exists today.