jschoubben
7b7096f37e
mesh/delivery-group group feat/take-in rejected: composed together: the checker's verdict at the members' heads (38623984d6ad): mesh-build-go
mesh/delivery closed: a newer head of the same pull request
mesh/check failed (2): mesh-build-go: the indexer's judge at the group's mesh-delivery head 7b7096f37ea76e1…; and 1 more | 7b7096f37ea7 on ae31b66a9e33
- A take-in releases its claims (compare-and-set, only while the claim is still its own) on a lost claim, on a claim it cannot read back, and on a merge it fails to take in: a claim left behind refused every later take-in until a restart. T5 row with a store that fails once, both ways. - The start step waits for nothing: with the build it runs unknown it says so and the forge consumer starts; a merged message left unacknowledged asks the build again (clause 1). T10 row: the start answers at once and takes nothing in. - A toolchain report evaluates pending again (ToolchainReported), since the build a revision names moves with the toolchain. T7 row: the revision is taken in once the report makes it name the running build. - The group's end is told by its whole subject (process.ModuleStreamSubject), so a repository named forge/group is never taken for one; row in the indexer's handle test. - The watchman asks the indexer's waits through indexer_pending at its start (invokes), before its durable consumer, which does not hear again what it acknowledged before a restart; the comment that said the whole stream is heard is corrected. W2 row: a wait seeded within its bound is raised past it. - bridge_groups names each group's last end ask, its who, why and when, and the bridge's answer (state end-asks). - The check's words for the indexer's rules: the trunk's manifest validator. - The bridge's end drops the merged-state test its merge commit already implies. - Test budget: groupask_test folded into groups_test, and the K1 mesh/check test into the owed status one: 804 unit tests (was 806). Claude-Session: https://claude.ai/code/session_01JG73KG7AfSdh6FP8VrBqCn
mesh-delivery
Novox Mesh — delivery: the parts that build, check and deliver a change by watching and writing keys on the bus (ADR 0429).
Made by the mesh from the gitea module's config value repositories (novox/hq ADR 0428). Main takes no push: a change reaches it by a pull request whose mesh/repo-check (this repository's merge-check.sh) and mesh/merge-gate passed.