mesh-catalog

novox/mesh-catalog

Fork 0

Author	SHA1	Message	Date
jschoubben	f97b7dd544	Undo: lavinmq cannot hold mesh-broker, and claiming it makes lavinmq unbuildable Putting the claim back was wrong on its own terms. `mesh-broker` delivers `mesh-bus`, and a seat that delivers a provision may only be held by a module that provides it — so the claim is refused at registration: lavinmq claims mesh-broker, whose holder answers for "mesh-bus", and lavinmq does not provide "mesh-bus" at mesh scope Which means the merged claim does not restore the holder, it stops lavinmq being built at all. Removed again. The seat being empty is still the live fault, and it has only one valid answer: the holder must provide `mesh-bus`, and the module that does is nats. Recorded against the rollout, because it moves a step that was optional into the critical path.	2026-09-27 21:27:55 +02:00
jschoubben	5f5798ec8a	Merge pull request 'lavinmq keeps mesh-broker until something else can take it' (#117 ) from fix/broker-seat-must-stay-held into main	2026-09-27 19:17:45 +00:00
jschoubben	42550dbe43	lavinmq keeps mesh-broker until something else can take it 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.	2026-09-27 21:13:13 +02:00

Author

SHA1

Message

Date

jschoubben

f97b7dd544

Undo: lavinmq cannot hold mesh-broker, and claiming it makes lavinmq unbuildable

Putting the claim back was wrong on its own terms. `mesh-broker` delivers
`mesh-bus`, and a seat that delivers a provision may only be held by a module that
provides it — so the claim is refused at registration:

  lavinmq claims mesh-broker, whose holder answers for "mesh-bus",
  and lavinmq does not provide "mesh-bus" at mesh scope

Which means the merged claim does not restore the holder, it stops lavinmq being
built at all. Removed again.

The seat being empty is still the live fault, and it has only one valid answer: the
holder must provide `mesh-bus`, and the module that does is nats. Recorded against
the rollout, because it moves a step that was optional into the critical path.

2026-09-27 21:27:55 +02:00

jschoubben

5f5798ec8a

Merge pull request 'lavinmq keeps mesh-broker until something else can take it' (#117 ) from fix/broker-seat-must-stay-held into main

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

jschoubben

42550dbe43

lavinmq keeps mesh-broker until something else can take it

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.

2026-09-27 21:13:13 +02:00

Compare commits

Diff Content Not Available