lavinmq keeps mesh-broker until something else can take it #117

2026-09-27T19:17:37Z

jschoubben commented

2026-09-27 19:17:37 +00:00

Live breakage, in progress. Taking the mesh-broker claim off lavinmq's manifest left the seat with nothing able to hold it, and the controller dereferences that seat to find its own bus. Unheld, the composed address fell back to a port nothing serves and the control plane began crash-looping:

mesh-controller: cannot reach the broker named in MESH_BROKER_AMQP:
  dial tcp 127.0.0.1:5672: connect: connection refused

mesh-controller seats confirms it: mesh-broker mesh amqp unheld.

The broker itself never stopped — it is healthy on the port the mesh assigned it, and all 52 containers on the node are running. What is down is the mesh's ability to change anything, which is the cost named in design 28 step 5.

lavinmq becoming an ordinary provider of amqp is right and unchanged. What was wrong is the order: a seat passes from one holder to the next and cannot be empty in between, because the thing that reads it is the thing that would have to fix it. The manifest line says lavinmq implements and can fill the seat; which assignment actually fills it is a separate question, and restoring the claim lets the existing assignment hold it again.

Live breakage, in progress. Taking the `mesh-broker` claim off lavinmq's manifest left the seat with nothing able to hold it, and the controller dereferences that seat to find its own bus. Unheld, the composed address fell back to a port nothing serves and the control plane began crash-looping: ``` mesh-controller: cannot reach the broker named in MESH_BROKER_AMQP: dial tcp 127.0.0.1:5672: connect: connection refused ``` `mesh-controller seats` confirms it: `mesh-broker mesh amqp unheld`. The broker itself never stopped — it is healthy on the port the mesh assigned it, and all 52 containers on the node are running. What is down is the mesh's ability to *change* anything, which is the cost named in design 28 step 5. lavinmq becoming an ordinary provider of `amqp` is right and unchanged. What was wrong is the order: a seat passes from one holder to the next and cannot be empty in between, because the thing that reads it is the thing that would have to fix it. The manifest line says lavinmq *implements and can fill* the seat; which assignment actually fills it is a separate question, and restoring the claim lets the existing assignment hold it again.

jschoubben added 1 commit 2026-09-27 19:17:37 +00:00

lavinmq keeps mesh-broker until something else can take it 42550dbe43

Taking the claim off made the seat unheld, and the controller dereferences that
seat to find its own bus (to-be 26, "the one exception is the controller itself").
Unheld, the composed address fell back to a default port nothing serves, and the
control plane crash-looped: "cannot reach the broker named in MESH_BROKER_AMQP:
dial tcp 127.0.0.1:5672". The broker itself never stopped — it is healthy on the
port the mesh actually assigned it.

lavinmq becoming an ordinary provider is right, and it is still a provider of amqp
here. What was wrong is the order: the seat has to pass from one holder to the next,
and it cannot be empty in between, because the thing that reads it is the thing that
would have to fix it.

jschoubben merged commit 5f5798ec8a into main

2026-09-27 19:17:45 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-catalog#117