4 Commits

Include renames

Author	SHA1	Message	Date
jschoubben	47205403d3	Wait out a forge not served for a moment when registering a build (novox/hq issue 486) ... A registration asked the forge while node-tools re-served after a tool-runner rollout, heard "nothing serves gitea.gitea_api", and failed a good build's plan. The bus's not-served answer is now link.ErrNothingServes (and a timeout link.ErrNoAnswer), and the registration asks again for up to 90 s on those alone, never on a refusal; past the bound it fails saying how long it waited.	2026-10-12 11:23:03 +02:00
jochen	be92762969	Give every test a bus of its own, at the release the mesh runs (hq ADR 0237) ... The live tests reached one shared bus and assert, read and remove the mesh's own objects by their fixed names, so packages run in parallel deleted what each other read and the suite passed only one package at a time; a red suite read as noise. internal/testbus starts a server per test, linked in at the nats-server release go.mod pins, and a test holds that pin to the catalogue's bus image and to the facts snapshot's bus when there is one, so the tests never run a bus the mesh does not. The waiter test read a timing (the most connections held at one look) and now reads the state it means (the fewest held across the wait). make check runs the packages in parallel under the race detector, with a timeout.	2026-10-06 21:17:02 +02:00
jschoubben	cc019908c2	Asking a tool goes through the seam, and loses two problems ... Step 3.4. On the new bus there is no reply queue to declare and no correlation to check: each account is granted one inbox prefix and no other, so an answer cannot reach the wrong asker. That settles a cost build.go records having paid — on a shared reply exchange every asker saw every result, which is why the correlation was checked rather than assumed. And a tool nobody serves says so at once rather than after the whole wait. The difference between "that module is down" and "that tool is slow" is the first thing a person asking wants, and both tests are against a real server because both are claims about what the server does, not about this code. RequestBuild stays as it is, and is a different shape on the new bus rather than the same one: a build takes minutes, so it is work submitted to a queue with the outcome returning to a reply subject the request carries — the pattern design 25 §2 already sets for anything crossing a stream. It touches the builder too, so it goes with that conversion.	2026-09-27 00:11:30 +02:00
jschoubben	2fad32767e	The controller's outbound link behind a seam, with both transports ... Step 3.4, first half. Every one of these took an *amqp.Channel, so the transport reached every caller and swapping it meant touching all of them. The seam turned out to be small — the controller sends exactly two kinds of message that expect no answer — which is the same measurement that said this bus could be replaced at all. Bus is stated in the mesh's words, not a transport's: PublishEvent and PublishDeclaration. Two implementations, both shipping, because steps 1 to 4 leave every node on AMQP and the NATS one is selected at the rollout. Both ship is also what makes them comparable: one conformance fixture holds both to the same envelope, and the NATS one is checked against a real server reading back from the stream rather than from the code that wrote it. Still on *amqp.Channel: RequestBuild and Ask, which carry reply-queue machinery, and the whole consume side — the control loop, enrolment, serve.	2026-09-26 23:47:15 +02:00