mesh-catalog/modules/mesh-delivery-gate

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 beside the module mesh-delivery, which the catalogue still holds, unchanged. The controller refuses a merge that removes a module that is assigned, so today's module stays in the catalogue until it is unassigned, and goes by a handover of verbs after the merge, never by hand on a machine (novox/hq ADR 0449 §4, ADR 0450 §6):

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).

After the handover, the removal of modules/mesh-delivery follows as a pull request of its own, merged by the gate; the catalogue then has one claimant of the seat. Until then the catalogue holds exactly these two, and the names of the old module that the handover needs, and no others: the three buckets the gate carries over, and the event the issue tracker and the tool runner hear until the module is forgotten (catalogue_test.go).