Building the bus: the decisions the work needed, and what it taught back #150

Merged
jschoubben merged 45 commits from feat/nats-genesis into main 2026-09-27 17:06:40 +00:00
Showing only changes of commit 51739c4302 - Show all commits
+23
View File
@@ -629,6 +629,29 @@ reserves them for after the move, and a flow built ahead of its design would be
**Why here.** It is the only step that moves a node's bus, and it moves every node's at once.
**The order the repositories land in is part of the rollout, not paperwork.** Derived 2026-09-27
while merging, and not obvious from any one repository, which is why it is written here rather than
left to be re-derived under time pressure:
| order | repository | why it cannot be later |
|---|---|---|
| 1 | this one | prose; nothing deploys |
| 2 | the sdk | comments only, and no module rebuilds for it |
| 3 | the client library | it is what a module calls to emit, and it is where the subject is derived. Until it lands, a locally-named event is published under the local name itself |
| 4 | the catalogue | every manifest and every module's code, renamed together. Safe only once the runtime derives |
| 5 | the controller | **it refuses an old-style event name outright**, so landing it before the catalogue makes every unconverted module unregisterable |
| 6 | the hosts | last, because nothing else waits on them |
Two properties make the sequence safe rather than merely ordered, and both are pinned by tests. A
name already in the old form passes through the derivation untouched, so a module nobody has
converted keeps working at every step. And a converted name derives to **exactly** the key the old
bus published, so steps 3 and 4 change nothing on the wire — the move to the new bus is step 5.2 and
one environment variable, not a side effect of deploying.
The failure this ordering avoids is issue 127's own: a publisher and a subscriber that disagree about
a subject produce no error anywhere. Nothing logs, nothing retries, and the mesh reports itself
healthy while reacting to nothing.
- [ ] 5.1 the cutover bed: a mesh on AMQP with a predecessor stand-in on the deprecated broker
moves its bus in one rollout, every node reporting on NATS afterwards, the stand-in's own
client still connected throughout