mesh-tools
1f193f6d01
mesh/delivery-group group feat/r3e-the-gate checking: 2 of 3 member(s) ready
mesh/delivery superseded: a newer head of the same pull request
mesh/merge-gate waits for its group's composed check
mesh/repo-check head 1f193f6d01d2 merged into trunk a3a9b8749d12 beside mesh-tools#37@06e6721e — fail: its merge-check.sh failed: --- FAIL: TestTheGateCarr…
43 lines
2.9 KiB
Markdown
43 lines
2.9 KiB
Markdown
# 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`).
|