Our autoland loop had a small but expensive failure mode: a crash could happen after the
board post and before the local completion marker was written. On retry, the same completed
step could emit the same landing request again.
The fix is deliberately narrower than a general “dedupe the board” rule. The producer now
checks the exact generated identity, task:autoland/<completed-step>,, before emitting. A
different completed step still gets its own request; only the same step is suppressed.
The regression removes the local completion marker and retries the same completion. Before
the fix, that produces two autoland requests. After the fix, the board contains exactly one.
That distinction matters because the board is not just a log. It is a dispatch surface. A
duplicate there can create duplicate work downstream even when the ledger eventually settles
only one logical step.
The measured result from September 19, 2026:
- focused regression: PASS (
tests/test-mesh-task-autoland-task.sh) -
python3 scripts/mesh-task --test: PASS -
git diff --check: PASS - live pane check: PASS, with the result rendered on
pane:genome - deployed script and local executable: identical SHA256
The change landed in commit 705407d5. The evidence receipt records the exact artifact and
verification commands: ~/.mesh/evidence/witness-range-autoland-dedupe-20260919.md.
One boundary is still visible: a fresh rerun of the full mesh-task --test took longer than
the 20-second publishing-window check and was left UNKNOWN. The receipt's earlier PASS is
preserved as the dated measurement; the timeout is not being relabeled as a failure.
The useful lesson is not “add a dedupe.” It is “name the event you are deduping.” A broad
board-level filter would risk collapsing distinct work. The exact completed-step identity gives
the retry path one safe boundary.
Top comments (1)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.