A build step names the process that runs it, so a restarted build module clears what a gone process left running (issue 1890) #105

2026-10-27T00:32:30Z

mesh-tools commented

2026-10-27 00:32:30 +00:00

Issue 1890 (notes 21-25): when a delivery replaced mesh-build-go on a node, a step left 'running' by the old process stayed for the step bound (30 min) and was counted as a busy build slot until ended by hand.

delivery.Step gains Owner (boot id, pid, process start); every write of a step keeps it.
The start sweep and the periodic round: a running step whose owner is not this process is cleared at once, loudly. An ask key is DELETED (revision re-read first), not ended, so the stream's redelivery still answers its asker (ADR 0525 §6); a hand-started step is ended failed (nothing redelivers it). A step with no owner (older build) keeps the old rule.
EndOne refuses a step this process owns. An unreadable boot id is said once at start.
Conformance kit case conformance.LeftRunning / JudgeLeftRunning for every build module.

Quick fix weighed: exempt nothing in mesh-build-go only; rejected, the other build modules keep the kind. Thorough fix chosen.
Known limit: mesh/state.delete takes no revision, so a few-ms window can drop a redelivered ask's running key until its next phase write (record only; no lost build, slot or check) - noted on 1890.

Delivery group fix/1890-step-owner with novox/mesh-catalog (the three build modules pin this head exactly).
Tests: whole untagged suite, go vet -tags integration pass; no new test functions.
Live case: the next delivery of mesh-build-go to a node with a running step leaves no 'running' key of the old process (mesh-delivery-view build usage), and its asker gets the redelivered answer.

Reviewed-by: review-1890@shanks at db1007ffdd

Issue 1890 (notes 21-25): when a delivery replaced mesh-build-go on a node, a step left 'running' by the old process stayed for the step bound (30 min) and was counted as a busy build slot until ended by hand. - `delivery.Step` gains `Owner` (boot id, pid, process start); every write of a step keeps it. - The start sweep and the periodic round: a running step whose owner is not this process is cleared at once, loudly. An ask key is DELETED (revision re-read first), not ended, so the stream's redelivery still answers its asker (ADR 0525 §6); a hand-started step is ended failed (nothing redelivers it). A step with no owner (older build) keeps the old rule. - `EndOne` refuses a step this process owns. An unreadable boot id is said once at start. - Conformance kit case `conformance.LeftRunning` / `JudgeLeftRunning` for every build module. Quick fix weighed: exempt nothing in mesh-build-go only; rejected, the other build modules keep the kind. Thorough fix chosen. Known limit: `mesh/state.delete` takes no revision, so a few-ms window can drop a redelivered ask's running key until its next phase write (record only; no lost build, slot or check) - noted on 1890. Delivery group fix/1890-step-owner with novox/mesh-catalog (the three build modules pin this head exactly). Tests: whole untagged suite, go vet -tags integration pass; no new test functions. Live case: the next delivery of mesh-build-go to a node with a running step leaves no 'running' key of the old process (mesh-delivery-view build usage), and its asker gets the redelivered answer. Reviewed-by: review-1890@shanks at db1007ffdda1452bf5aefff878183b45960ef1d5

mesh-tools added 2 commits 2026-10-27 00:32:31 +00:00

End a step left by a previous process at once: every step names its owner (issue 1890) 981a35b598

A delivery that replaced mesh-build-go left a check ask's key running, and
the new process's start sweep spared it as an ask younger than the step
bound, so it held a build slot until a hand end (issue 1890, note 21).
Each step now records its owner (boot id, pid, process start); the sweep
ends a running step of another owner at once and says its owner, while a
key with no owner keeps the earlier rule. The conformance kit gains the
left-running case every build module runs through its own start sweep.

Delete a gone process's ask key instead of ending it, so its redelivery still answers the asker (issue 1890)

mesh/delivery merged: source.main moved to novox/mesh-sdk@43eef46c4121

Details

mesh/delivery-group group fix/1890-step-owner merged: every member is merged

Details

mesh/check pass db1007ffdda1 on b0cbc4e6aca8 | unit 6014 run, 233 kept, 16 skipped | integration 6067 run, 265 kept, 24 skipped | over bound: unit, in…

db1007ffdd

ADR 0525 §6 has the stream redeliver an ask whose node stopped, and the
asker takes the first end it reads: ending the key at a restart failed
checks a redelivery would still run. The sweep now deletes such a key,
guarded by the revision read, so the asker keeps waiting and the stale
key leaves the counts of what runs; a hand-started step of a gone owner
is still ended at once. A missing boot id is said once at start.

mesh-tools commented

2026-10-27 00:32:34 +00:00

Delivery novox/mesh-sdk@db1007ffdda1 — merged since 2026-10-27T07:19:38Z

Source — source.main moved to novox/mesh-sdk@43eef46c41. Whether it reached the machines is mesh-delivery-view's, derived from source.main, the wants and the haves.

Group fix/1890-step-owner: novox/mesh-catalog@39419b1892, novox/mesh-sdk@db1007ffdd

composed together: pass — the checker's verdict at the members' heads (712e7f959492)

Transitions

2026-10-27 00:32 (new) → proposed (announced): novox/mesh-sdk#105's head announced
2026-10-27 00:32 proposed → ready (accepted): a verdict names this commit and the trunk's head as its trunk commit, the gate passed or warned, and the repository's own check did not fail; or the check gates no merge (check-gates-merge false)
2026-10-27 07:19 ready → merged (merged): on the trunk its modules follow: merged there

The commit's note under refs/notes/mesh-plan keeps every transition of this change up to its merge: git log --notes=mesh-plan.

**Delivery** `novox/mesh-sdk@db1007ffdda1` — **merged** since 2026-10-27T07:19:38Z **Source** — source.main moved to novox/mesh-sdk@43eef46c4121. Whether it reached the machines is `mesh-delivery-view`'s, derived from `source.main`, the wants and the haves. **Group** `fix/1890-step-owner`: novox/mesh-catalog@39419b1892c9, novox/mesh-sdk@db1007ffdda1 - composed together: pass — the checker's verdict at the members' heads (712e7f959492) **Transitions** - 2026-10-27 00:32 (new) → proposed (announced): novox/mesh-sdk#105's head announced - 2026-10-27 00:32 proposed → ready (accepted): a verdict names this commit and the trunk's head as its trunk commit, the gate passed or warned, and the repository's own check did not fail; or the check gates no merge (check-gates-merge false) - 2026-10-27 07:19 ready → merged (merged): on the trunk its modules follow: merged there The commit's note under `refs/notes/mesh-plan` keeps every transition of this change up to its merge: `git log --notes=mesh-plan`.

mesh-tools commented

2026-10-27 00:32:41 +00:00

mesh-delivery: the operator's Approve of this pull request's merge into main is ended: a head it covers moved on: the heads it covers are no longer the group's heads. Nothing is merged on it. The operator is asked again once the checks pass at the new head.

mesh-tools merged commit 43eef46c41 into main

2026-10-27 07:19:36 +00:00

mesh-tools deleted branch fix/1890-step-owner

2026-10-27 07:19:37 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-sdk#105