Issue 335: leave fixed-by for the merge, and call the put-back refusal a guard
mesh/merge-gate pass: the change touches no module of the mesh's graph
mesh/repo-check pass: its merge-check.sh passed
mesh/delivery superseded: a newer head of the same pull request

This commit is contained in:
jochen
2026-10-08 20:49:40 +02:00
parent b409537dbc
commit f346efb938
@@ -2,7 +2,7 @@
status: located
opened: 2026-10-08
located-in: [mesh-controller cmd/mesh-controller (release_plan.go, nextRollout and failFirstSend)]
fixed-by: mesh-controller#165, mesh-lab#72
fixed-by:
replay: R335
amended-design:
---
@@ -37,17 +37,22 @@ build that worked, recorded it as failed, and so blocked its delivery until a ne
## Fix
The controller judged the first machine's report again on every step of the walk, also after the gate had
passed (see `01-diagnosis.md`). mesh-controller#165:
passed (see `01-diagnosis.md`). The fix is proposed in mesh-controller pull request 165, with its replay in
mesh-lab pull request 72; `fixed-by:` is filled when they merge.
- once a module's gate has passed, the first machine's later reports no longer decide anything about it:
the walk sends the rest;
- a module carried by another module's send takes over that pass before its step is read;
- a walk stopped after a module's gate passed never puts that module back, and says what stopped it.
- Once a module's gate has passed, the first machine's later reports no longer decide anything about it:
the walk sends the rest.
- A module carried by another module's send takes over that pass before its step is read.
- A guard, not reached with the two changes above: should a later path still stop a walk at a module whose
gate passed, that module is not put back and its build is not marked failed. The walk stops with the
reason, and the module is left sent to its first node only, which `plans retry` takes up again.
## How it is checked
`TestReplay335` in the controller replays the live case with only what the controller had before the fix:
a passed gate on the laptop, the laptop's later report not about this build (or a failure of another
send), and the walk 30 minutes and 9 seconds after the first send. On the commit before the fix it fails
send), and the walk 30 minutes and 9 seconds after the first send. A second test drives the walk over a
tier of two modules, the second carried by the first's send, and fails if the carried module's step is read
before it takes over the pass. On the commit before the fix it fails
with "laptop did not report it applied within 30m0s", and the passed build reaches the put-back. It is R335
in mesh-lab's replays register (mesh-lab#72), proved to fail before the fix and pass on it.
in mesh-lab's replays register, proved to fail before the fix and pass on it.