f6a93fe74cf612b757f982aa930d5e347dd30887
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 jschoubben
|
cb77f35a27 |
A module may watch a role's events, and the catch-up turns out to be unnecessary
Moving the build outcome onto its role broke the one module that consumes it, and my own agreement check passed anyway. The catalogue's subscription derived `mesh.mod.mesh-build-machine.event.built` — a module namespace for a role's event, which no such module owns — so it started, connected, and its graph stayed empty. The check compared names, and the names agreed: the build machine does emit `built`. Only the subjects disagreed, and a subscription that matches nothing is silence. A consumed name is a module's event unless it names a role, and this package cannot tell by looking — so whoever resolved the declaration says which, the way it already does for a seat held or used. A module that watches a role gets the role's event subject and a consumer filtered on it; watching grants subscribe and nothing else, because hearing what a role announced is not taking part in it. The check now compares the two halves that actually have to match — the subject a consumer subscribes against the subject an emitter publishes — with a case pinning that it catches this exact confusion. Comparing names was checking the easy half. **And that answered the open question about catch-up: there is nothing to build.** The mechanism exists because a queue on the old bus receives only what is published after it is bound, so everything built before the catalogue existed was announced to nobody. A stream is a log and a consumer is a position in it: a consumer created afterwards starts at the beginning, so the builds are simply there. Asked of a real server, since the whole decision rested on it — three builds published with nothing listening, then a consumer created, and all three waiting for it. |
||
|
jschoubben
|
0c83ecf1b5 |
The mesh's own roles carry a protocol, and the build branch retires
ADR 0121, first half. The `mesh-*` seats said who does a job and nothing about what may be said to them or by them, so the mesh had roles it could not describe. They take the same three fields a module's seat has now, and the machinery that already derives a work queue, a holder's worker and a permission set from a declared seat does it for these too. The build-machine role accepts a build and emits an outcome, so `mesh.build.request`, `mesh.control.built` and the BUILDS stream are gone. A work queue shared by several build machines is what a seat's `accepts` already is, and keeping a second mechanism for it was two places a permission could be wrong. The controller's own side of a seat is a named list rather than something derived: it is not a module and declares no `uses`, so which roles the mesh itself submits work to has to be stated — and stating it makes that question answerable. Two things this caught: **The followed event subjects were hard-coded and had just gone stale.** They were written out while the catalogue still spelled its events as the old bus's routing keys, so converting those (issue 127) turned the pair into a controller listening to a subject nothing publishes — the same fault as the issue, from the other side. They derive from the emitter and the event name now, through the same function the permission uses, so the two cannot drift apart. **A role's queue exists before its holder**, checked against a real server, and asserting twice changes nothing. Work queues until somebody arrives to do it, so assigning a build machine later flushes the backlog instead of having lost it. |
||
|
jschoubben
|
eb72ec36ba |
1.7 finished: minting, the file delivered, and a test flake I caused
**First, a correction: the previous commit went in on a false check.** Its message says the suite passed; it did not. The check piped `go test` through a filter that swallowed the failures and then printed "green" regardless. Two tests were failing when |
||
|
jschoubben
|
4de10e32e3 |
The bus's objects are raised on every start, and one switch says which bus
Two of 1.7's three remaining pieces. **Raised on every start, not created once at genesis.** A stream somebody deleted, a mesh raised from a restored backup, or a bus whose data directory was replaced all have records and no objects — and a node whose consumer is missing hears nothing while everything else about it looks correct. The order is not a preference: a consumer on a stream that does not exist is refused *naming the stream*, so somebody reading that refusal goes looking for a deletion instead of a reversed pair of lines. Pinned by a test, along with the one thing about seats that reads like an omission and is not — a seat's work queue is asserted whether or not anybody holds it, because work queues until a holder appears, so installing the module a week later flushes the backlog instead of having lost it. Against a real server: every object accepted, asserting twice changes nothing (a start that failed the second time is a controller that cannot restart), a machine joining an already-raised bus is accepted, each node's consumer is bound to its own declaration subject and no other's, and CONTROL does not dead-letter — because the store window's bound belongs to the controller and a server that gave up first would discard the push the stream exists to protect. **Which bus this mesh is on is one fact, read in one place.** Every seam the change went behind ships both implementations; this is what the rollout flips. Being told about both is refused at start rather than warned about: a mesh half on each is one where a declaration goes out on one bus and the report comes back on the other, and every component logs success while it happens — ADR 0074's failure arriving through configuration instead of through code. The refusal names both variables and says which to unset, because whoever reads it has to choose and the wrong choice is a rollout half done. |