diff --git a/04-ISSUES/319-a-held-delivery-a-later-commit-superseded-has-no-end-but-release/01-diagnosis.md b/04-ISSUES/319-a-held-delivery-a-later-commit-superseded-has-no-end-but-release/01-diagnosis.md index 9a4a2de4..89a11b1e 100644 --- a/04-ISSUES/319-a-held-delivery-a-later-commit-superseded-has-no-end-but-release/01-diagnosis.md +++ b/04-ISSUES/319-a-held-delivery-a-later-commit-superseded-has-no-end-but-release/01-diagnosis.md @@ -46,3 +46,64 @@ Neither considers a held delivery whose content a later commit delivered. **Located** in mesh-delivery's state table (no end for a superseded or empty held delivery, and history read by how a delivery was made) and in to-be 47, whose state table carries the same gap. + +## 2026-10-09 + +**Eleven held deliveries, read again.** On 2026-10-09 eleven deliveries were `held`, each raising D14's +`delivery..stalled` and held for 24 to 48 hours. For each, `mesh-delivery.show` gave its state, why it was +held, its merge commit and its plan. A fresh clone of the repository then showed whether the merge commit is an +ancestor of the commit a finished walk delivered. `mesh-controller.status` listed none of the modules involved +as behind. All eleven were covered: none held a change missing where it should run. + +**Why the controller opened no walk (open question 3).** This part comes from reading the code, and part of it +is still a guess. + +- *A new module.* When a merge only adds a module, the controller's `SourceMoved` + (`cmd/mesh-controller/upgrades.go`) builds and registers it, sends it nowhere and opens no walk ("built, + registered when the build lands, and sent nowhere", issue 300). mesh-delivery's `MovesNothing()` + (`model.go`) counts `Plan.New` as something to move, though. So a delivery whose plan is "builds new: …, sent + nowhere" is not let through to `published` → `delivered`. Instead the unwalked rule in `holder.go` holds it + ten minutes after its merge: "merged, and the controller opened no walk for it within 10m0s". That is a fact + read from the code, and it matches `novox/mesh-catalog@60641176abaf`. +- *The controller's own merges (a guess, not proved).* `SourceMoved` also returns without a plan in two cases: + when the modules the merge touches are "already built from it" (`already > 0`), and when the merge is read as + history (`isHistory`: merged before the source was last looked at). Either would leave a merge with no walk + of its own when another walk, or a person's push, had already built from a later commit. Which of the two hit + these merges is not yet known. The controller's journal for the minutes after each merge would say. +- *The link from a walk to a delivery.* `deliveryWalking()` (`holder.go`) links a walk to the delivery whose + `merged_as` equals the walk's commit, and to no other delivery. A later walk that carried an earlier merge's + change therefore never reaches that earlier delivery, and nothing reads "this walk's commit contains your + merge". That is the missing input the first open question asks about. mesh-delivery could answer it from the + forge (is the merge commit an ancestor of the delivered walk's commit) together with the walk's moved modules, + without asking the controller what each machine runs. + +**Four were closed with `stop`, before this issue was found.** On 2026-10-09 the operator agreed to close the +held deliveries. Four were stopped with why "covered: its merge … is contained in … which is delivered (walk …)": + +| delivery | merge | contained in | walk | +|---|---|---|---| +| `novox/mesh-controller@ec3769a8a669` | 099c176 | cec797e (the controller's main) | a finished three-tier walk of the controller | +| `novox/mesh-controller@ea09f074db01` | e7dca6c | cec797e | the same walk | +| `novox/mesh-controller@98ef7bac6e6a` | cdbbd9e | cec797e | the same walk | +| `novox/mesh-catalog@60641176abaf` | 3da80a4 | a1406e7 (the catalogue's main) | a new module sent nowhere; a later finished catalogue walk | + +Their stalled conditions cleared at the next D14 observation. Open D14 conditions went from 11 to 7. As this +issue already said, `stop` is the wrong record for them: their merged pull requests now carry `mesh/delivery` += error, "stopped: covered: …" (`effects.go`, `Stopped` → `error`). This blocks nothing, because they are +merged. But the forge now records a delivered change as stopped, and a final state cannot be undone. The +remaining seven were left `held` for this issue's fix. + +**The seven still held**, and why each is held: + +| delivery | why held | covered by | why it was not stopped | +|---|---|---|---| +| `novox/hq@055550802096` | merged without a passing check | merge on hq's main; builds nothing | held for a different reason than the controller's merges; builds nothing | +| `novox/hq@2221be11a6ef` | merged without a passing check | merge on hq's main; builds nothing | the same | +| `novox/hq@897bcce50252` | merged without a passing check | merge on hq's main; builds nothing | the same | +| `novox/hq@ef6ab814b053` | merged without a passing check | merge on hq's main; builds nothing | the same | +| `novox/mesh-controller@b98fd0f396c8` | no walk opened within ten minutes | 7f25666, contained in cec797e | a member of a group still `delivering` (2 of 3); `stop` stops the group's later members too | +| `novox/mesh-controller@ea92af2a7d77` | no walk opened within ten minutes | 3808634, contained in cec797e | `show` lists a step still `judging` on the control-node, carried by a release walk that is done; the step looks stale but is not final | +| `novox/mesh-catalog@66106d93accd` | its group's composed check did not pass for the heads that merged ([issue 316](../316-a-group-member-held-before-its-composed-check-answered-stayed-held-after-it-passed/00-report.md)) | 7cd989b, contained in a later finished walk of the same module | its group is still `delivering`, and its own walk is `superseded` | + +The seven show the two ends this issue asks for: four hold nothing to deliver, and three are covered by a +later walk.