lane-handoff reads the lane lifecycle through a pipeline whose awk exits early, so under pipefail the read dies of SIGPIPE (exit 141) now and then and the handoff records no transition #280

What happens

lane-handoff reads the lane's lifecycle through a pipeline that can die of SIGPIPE.

• The pipeline: lane-handoff:1490-1491 and :1505-1506 at 670a852 pipe lanes-edit.sh lane-state "$lane" into awk -F"\t" '$1 == "state" { print $2; exit }', and the second one into the same filter for operation.
• The race: the script runs under set -uo pipefail (lane-handoff:120). awk exits as soon as it has printed its one field. If lanes-edit.sh writes again after that, the write gets SIGPIPE, lanes-edit.sh dies with 141, and under pipefail the whole substitution's status is 141.
• What the handoff does then: case "$lcb_rc" in 0 | 8) takes 141 as a failed read. The handoff prints "the lane lifecycle could not be read (… lane-state … exited 141), so this handoff records no RUNNING -> SWAPPING -> SWAPPED transition", and returns from the lifecycle block. It records no fence, takes no inventory, and makes no transition.
• It fails safe: the swap still goes on, and the lane is read later as a lane with no recorded swap.
• But it is wrong, and it depends on timing alone. The read did not fail: the reader stopped listening.

How it was found

• The run: CI run 39322387035, on lane 3's prefix lane3-queue/q5c-228t025-on-q4e (quickstart.md has been run and its three wrong passages fixed, the 006 docs cite the tests where they now sit, and the partial-stamp example is the line stamp_read prints (#228) #270, docs only, on top of The record tells the truth about releases: the v1.0.0 notes are in the repository, the v1.1.0 notes are drafted, and README says what a release is, what --version prints and what a workstation with pipx's link sees (#228, PR 4 of 4) #269).
• The failure: 1 failed, 2742 passed, in tests/test_triad_lane_tooling_handoff.py::test_t018_the_handoff_reports_a_leg_git_cannot_read_as_the_sweep_counts_it (:600 → :553).
  • The handoff's stderr says … lanes-edit.sh lane-state triad-1 exited 141.
  • So the expected line, "the worktree inventory entry for … was NOT written: the assembly has 1 unreadable leg(s) …", is never printed.
• It is intermittent: the same test passed on the same code one prefix down (q4e, run 39322369835) and in every run before it.
• The runner image was the one that started rolling out on 2026-10-19 (ubuntu-latest moving to Ubuntu 26, git 2.55.0). It may change the timing, but not the cause.

Where else

The same shape occurs elsewhere: a command whose output is read by a consumer that stops early (awk … exit, head -1), under pipefail. At 670a852, by grep:

• lane-handoff: 32 | awk … exit } pipelines and 2 | head -1;
• lanes-edit.sh: 18 and 27;
• lane-start: 19 and 1;
• lane-end: 0 and 1.

Only the ones whose producer writes in several pieces can race. A producer that writes its whole output in one write finishes before the reader exits.

The fix

• For the lifecycle reads, read the whole output first, then parse it: lcb_raw="$(… lane-state "$lane" 2>/dev/null)" || lcb_rc=$?, then awk on printf '%s\n' "$lcb_raw". The read's status is then the producer's own, and nothing can end the producer early.
• For the other sites, audit each pipeline fed by a command. Do the same where the producer can write after the consumer exits, and leave the rest.
• Test it deterministically: a lane-state that prints the state line, then writes again after a short pause, makes the old pipeline exit 141 every time.

Why now

Every PR's tests job runs the T018 test, so the race can turn any PR's CI red at random. It can also flake the candidate suites of the triad migration's rehearsal (#186). Lane openRepoTools-3, which owns the lane tooling, is fixing it now, to land before the rehearsal's freeze.

Lane: openRepoTools-3

🤖 Generated with Claude Code