jschoubben
ce6ae943b7
Both lines of work numbered from the same point, so four decision records and one design document existed twice with different content. The trunk keeps its numbers and this branch yields — the only rule that scales, because the trunk's are already cited by what merged before them. 0117 the bus is the only broker -> 0125 0118 a module declares its own seats -> 0126 0119 amqp is a provision, not the bus -> 0127 0120 the mesh bus is required -> 0128 0123 a seat carries its role's protocol -> 0129 0124 the predecessor is ending -> 0130 design 29, what a module declares -> design 32 Applied to the code repositories too, because a stale reference is worse when numbers collide than when they dangle: the reader lands on a real record that decided something else. Two reconciliations the merge forced, both real: **0110 was marked wholly superseded and was not.** Its successor says in as many words that everything 0110 decided about what a seat *is* stands untouched — and two records that landed on the trunk rest on exactly that part. So it is accepted again, extended rather than replaced, with a note saying which of its claims moved and where. **A seat's protocol becomes columns, not fields.** The trunk moved the seat set out of compiled code into a table the controller owns. This branch had added what a role accepts, emits and serves to the Go slice. The decision is unaffected and the mechanism is better for it: giving a role a protocol is now a write rather than a rebuild, which is the trunk's own argument applied to what this branch added. One check still fails and it fails on main too: a record resting on ADR 0112 while that is still 'proposed'. Left alone — it is not this merge's to answer.
3.6 KiB
topic, status, date, deciders, reconstructed, extends
| topic | status | date | deciders | reconstructed | extends |
|---|---|---|---|---|---|
| the mesh | accepted | 2026-09-27 | jochen | false | 02-DECISIONS/0127-amqp-is-a-provision-not-the-bus.md |
130. The predecessor is ending, and its broker goes with it
Context
ADR 0127 settled that the old broker is an ordinary
provider of the amqp provision rather than a compatibility module with an end date. It rejected
giving it a retirement condition, and said why: "its clients are not only the predecessor's, so the
retirement condition describes a day that will not come."
The operator has said that day is coming. The predecessor is deprecated. Some of it is still running, and it is not being migrated — it is being left to stop. Its broker may be shut down.
That is a fact about this installation, not a change of mind about what a broker is. It is recorded because three documents reason from the premise it overturns: design 25 §5 and §9, and design 28's closing note that the predecessor's world "does not need to move: its broker is the compatibility module until its last client is gone."
Decision
The predecessor's broker retires when nothing requires amqp, by being unassigned like any other
provider. No retirement condition, no end-date machinery, no special case — which is ADR 0127 being
paid off rather than revised. Because that record made the broker an ordinary provider, ending it
needs nothing that does not already exist: a provision with no consumers has its provider unassigned,
and the module system has done that since it existed.
So step 5.3 has an ending. "The mesh's own accounts removed from the deprecated broker" was written as the last thing that could be said, because the broker itself was going to outlive the question. It now finishes: once the mesh's own traffic has moved and the predecessor's remnants have stopped, the module is unassigned and the port is free.
And the transitional doubling has a date. The build outcome is announced under both the module's name and the role's on the old bus, so that a catalogue deployed before the rename and one deployed after both hear it. That exists only while the old bus does, and goes with it.
Consequences
The remote access path goes with it, and that is the one practical consequence worth planning around. The predecessor's own mesh communicates over that broker — so shutting it down ends the tooling that reaches this installation's machines remotely. Work on the node after that point is done from the node. This matters most for the rollout, which is the step that would otherwise be driven from a workstation: it has to be driven locally, or driven before the broker stops.
What is still running on it stops when it stops. Some of the predecessor's services are live and are not being moved. That is the operator's decision and it is recorded here so that nobody later reads a broker with clients as an accident.
Nothing in a served request's path is affected. Modules serve from their own containers; the mesh's bus carries the mesh's own traffic — declarations, reports, events, tool calls. This was checked rather than assumed when the question came up, and it is why the operator's position ("as long as my services keep running") is a bounded risk rather than a gamble.
One reason to keep the broker survives: amqp remains a provision a module may require, and a
module that genuinely needs an AMQP broker can be given one. What retires is this broker's role as
the predecessor's, not the mesh's ability to provide the thing.