jschoubben
94fee5d849
The glossary's authority page still named the controller's seat the-controller in two entries, contradicting its own seat section after ADR 0079; issue 058's heading kept the pre-renumber 059; 055's fixed-by named branches that stop existing after merge (now merge commits/PRs) and its located-in listed file paths where the convention wants repos; 056's located-in named mesh-host, which received no fix, instead of mesh-catalog; and the design layer never said the one-store/one-broker property is enforced — 07-the-foundation and the installation table now state the seats. https://claude.ai/code/session_01D6qtiYU3P9jk3pnAXyAFyx
3.2 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | ||
|---|---|---|---|---|---|---|
| resolved | 2026-09-17 |
|
mesh-catalog + mesh-controller (the foundation modules claim mesh-scoped seats) | 02-DECISIONS/0079-the-foundation-seats-are-named-after-their-servers.md |
056 — An adopted module assigned to a second node raises a second server
Symptom
The store and broker are adopted in place (ADR 0078,
issue 051): genesis raises mesh-store/mesh-broker on the control-node, and assigning the
postgres/lavinmq module there makes the module reconcile the already-running container instead
of raising a new one. Adoption works because the container is already running on that node.
Nothing stops the same module being assigned to a second node. On a node where no
mesh-store is running, the applier finds no container by that name and raises one — a second
postgres, a second broker. The whole point of Phase 3 — "one postgres, one lavinmq" — holds only
by the convention that genesis assigns these modules to the control-node alone; it is not enforced.
Why it matters
"There is one store and one broker" is stated as a property of the mesh, and a property enforced by
nothing is indistinguishable from a wrong one. A single extra assign — the ordinary verb an
operator types — silently produces a divergent second server holding none of the first's data, and
consumers resolved to it get an empty store. The failure is silent and far from its cause.
The exclusive foundation modules are the mesh's clearest case of "there is one of me," yet unlike a mesh-scoped seat, an adopted module carries no claim that the resolver would refuse a second holder for.
Open questions
- Should
postgres/lavinmqclaim a mesh-scoped exclusive seat (the waymesh-controllerclaimsthe-controller), so the resolver refuses a second assignment by the same mechanism that keeps one controller? - Or should adoption be explicit — a module that adopts a foundation container declares it, and the controller refuses to place it on a node whose foundation did not raise that container?
- How is "one postgres, one lavinmq" checked, rather than assumed — in the resolver, in
status, or in a bed that tries the second assignment and asserts the refusal?
Resolution (2026-09-17)
The foundation modules now claim a mesh-scoped seat named after the server each guards —
postgres claims mesh-store, lavinmq claims mesh-broker, and the controller's seat is
renamed the-controller → mesh-controller so all three follow one convention
(ADR 0079). The
resolver's checkClaims refuses a second holder mesh-wide — the same mechanism that keeps one
hub and one controller — so a second assign is a refusal at resolution (one per mesh), not a
silent second server.
Checked by TestAFoundationModuleCannotBeRaisedOnASecondNode (each foundation module's second
assignment is refused) and by the manifests declaring the seat; the two-node adopted-broker bed
stays green with the seats in place, so the claim does not break single-node adoption.