Files
mesh-catalog/modules/mesh-delivery-gate/README.md
T
mesh-tools 1c7024224d
mesh/merge-gate head 1c7024224dd7 merged into trunk bb0fe93bbddd — pass: builds mesh-delivery, mesh-issues → novox; no bus step; every machine composes wit…
mesh/repo-check head 1c7024224dd7 merged into trunk bb0fe93bbddd — pass: its merge-check.sh passed, each part in its toolchain: merge-check.sh (go), merge-…
mesh/delivery delivered
Make the catalogue test strict: the gate alone claims the seat, and say the old module is gone (ADR 0454, issue 1351)
2026-10-20 12:03:46 +00:00

2.9 KiB

mesh-delivery-gate

The mesh-delivery-gate module of the mesh catalogue: the gate of design 47. It claims the seat mesh-delivery, whose name stays (ADR 0437 §11), and takes over from the module mesh-delivery (ADR 0437 §3, ADR 0450 §6). Its buckets are mesh-delivery-gate_*.

Files it does not know

Each directory or archive this module declares says how it treats a file it did not write (ADR 0422, ADR 0416).

  • ${dir:state}: everything in it is the program's; the mesh moves nothing out (ADR 0422 §2).

A backup that failed before the send

The controller backs up the data of the modules a delivery moves before it asks or sends anything (ADR 0404). When its walk's record, in plan-moved, names a backup that failed or stayed silent and nothing of the plan was sent, the delivery goes from delivering to held (the observed row backup failed); the held reason names the machine, the module and the backup's words, and the pull request's comment shows it. The hold does not lift by itself. release of such a delivery asks the controller (delivery-backups-again) to take the backups again and the delivery goes on delivering; a record from before the controller cleared the failure does not hold it again. A held delivery already ends as covered or delivered when a later merge covers it.

Taking the seat over from today's module

The gate claims the seat mesh-delivery and took it over from the module mesh-delivery, which the catalogue no longer holds. The controller refuses a merge that removes a module that is assigned, so today's module stayed in the catalogue until it was unassigned, and went by a handover of verbs after the merge, never by hand on a machine (novox/hq ADR 0449 §4, ADR 0450 §6, ADR 0454):

  1. assign mesh-delivery-gate to the machine that holds the seat (mesh-controller.assign);
  2. check that mesh-controller.seats still names mesh-delivery, held by the running module;
  3. unassign mesh-delivery from that machine (mesh-controller.unassign) and push it (mesh-controller.push);
  4. the seat passes: the gate reads the controller's assignments and the node-engine's have keys, finds the module on no machine, carries its deliveries, groups and pull keys over once (the key carried in its deliveries says it did), reads the controller's walks and the forge's open pull requests, and acts.

Until then the gate is silent: it takes no event, writes no key, asks nothing and answers no verb but delivery_status, which says why (holds-the-seat, seat-waits).

The removal of modules/mesh-delivery followed the handover as a pull request of its own, merged by the gate (ADR 0454); the catalogue has one claimant of the seat, and no manifest but the gate's and the issue tracker's names the old module but the names the handover needed: the three buckets the gate carries over, and the event the issue tracker and the tool runner hear (catalogue_test.go).