Issue 146: a first node now enrols, and is enrolled twice #185

2026-09-29T15:37:50Z

jschoubben commented

2026-09-29 15:37:50 +00:00

Two more faults behind the three already merged, and one still open.

The account a token is the password of was never recorded. The composer names an enrolment user for every machine with a live token; nothing minted a credential for it, so the composition left it out as a user with no password. The comment above the issuing code already claimed the account is created before the token is handed over — which is how it went unnoticed.

The composed list has to be placed by hand at genesis. It reaches the machine running the bus in that machine's declaration, and a machine that has not enrolled gets none. So the control plane says what it composed (broker accounts) and whoever raises the machine writes it beside the bus. Twice, because two accounts come into existence at different moments.

With both, a first node enrols against the bus it just raised — measured from bare in the lab, which had not been possible since the cut-over.

Still open: one enrol produces two enrolments, each minting a credential; the machine keeps the answer to the first and the mesh keeps the second, so it reconnects for ever as a user whose password the mesh rotated. The diagnosis says what is ruled out and where the trail stops. The mint is the fragile part rather than the delivery: an enrolment answered twice cannot be answered the same way, because the mesh keeps only the hash.

Companion branches: mesh-controller fix/a-token-is-an-account-on-the-bus, mesh-host fix/a-node-can-join-the-bus-the-mesh-runs-on, mesh-lab feat/the-trust-bed-raises-a-mesh.

Two more faults behind the three already merged, and one still open. **The account a token is the password of was never recorded.** The composer names an enrolment user for every machine with a live token; nothing minted a credential for it, so the composition left it out as a user with no password. The comment above the issuing code already claimed the account is created before the token is handed over — which is how it went unnoticed. **The composed list has to be placed by hand at genesis.** It reaches the machine running the bus in that machine's declaration, and a machine that has not enrolled gets none. So the control plane says what it composed (`broker accounts`) and whoever raises the machine writes it beside the bus. Twice, because two accounts come into existence at different moments. With both, **a first node enrols against the bus it just raised** — measured from bare in the lab, which had not been possible since the cut-over. **Still open:** one `enrol` produces two enrolments, each minting a credential; the machine keeps the answer to the first and the mesh keeps the second, so it reconnects for ever as a user whose password the mesh rotated. The diagnosis says what is ruled out and where the trail stops. The mint is the fragile part rather than the delivery: an enrolment answered twice cannot be answered the same way, because the mesh keeps only the hash. Companion branches: `mesh-controller fix/a-token-is-an-account-on-the-bus`, `mesh-host fix/a-node-can-join-the-bus-the-mesh-runs-on`, `mesh-lab feat/the-trust-bed-raises-a-mesh`.

jschoubben added 1 commit 2026-09-29 15:37:51 +00:00

Issue 146: a first node now enrols, and is enrolled twice f6ed3545b7

Two more faults behind the three already fixed. The account a token is the
password of was never recorded, and the comment above the issuing code said
it was; issuing now records it. Placing the composed list at genesis is the
other half — the control plane says what it composed and whoever raises the
machine writes it beside the bus, because no declaration can reach a machine
that has not enrolled.

With that a first node enrols. It is then enrolled twice from one attempt,
each minting a credential, and it keeps the answer to the first while the mesh
keeps the second. The trail for that one stops at a duplicate that survived
message-id deduplication.

jschoubben added 1 commit 2026-09-29 15:45:27 +00:00

Issue 146: what made it slow, and what was changed so it is not e9b1010bc0

jschoubben added 1 commit 2026-09-29 19:32:53 +00:00

Issue 146: the double enrolment was two consumers sharing a delivery subject eef54917ec

Not about enrolment. A push consumer delivers onto an ordinary subject and
everything subscribed to it gets a copy; the controller's two consumers were
both named after it, so both were given the same subject and the one process
acted on every message twice. Enrolment is where it drew blood because a second
enrolment mints a second credential.

jschoubben added 1 commit 2026-09-29 19:39:58 +00:00

Issue 147: the operator's tools still dial the bus that was removed 0dd00e88b6

Every tool call fails with 'AMQP not connected', on every node including the
local one, because the tool surface still opens an AMQP connection and that
transport was deleted at the cut-over. The mesh reports healthy throughout —
what broke is the thing standing outside asking it questions, so nothing the
mesh checks is about it.

jschoubben added 1 commit 2026-09-29 19:50:52 +00:00

Issue 147: the tool surface is not the mesh's, it is the predecessor's 3c0f7082e6

Diagnosed from the configuration: the tool server is HAL's brain, a local
process on the workstation with the predecessor's broker URL in the assistant's
own config. No manifest, no assignment, no seat, no account. Nothing regressed
— the mesh removed a transport this program still dials, and the program was
never part of the mesh. The mesh has a tool model and nothing publishes an
operator-facing surface onto it.

jschoubben merged commit fcba05fed9 into main

2026-09-29 21:36:42 +00:00

jschoubben deleted branch issue/146-diagnosis

2026-09-29 21:36:43 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/hq#185