Files
zooqueen 3c93d455c1 actions: a task that let go of its job must not settle it later
Not re-queued did not mean still ours. The sweep can hand a dropped job
back and a second runner claim it before the first runner's report lands,
and the fallback write settled whatever job it found: a job actively
running another task went to Failure, the emitter skipped everything
downstream of it, and those jobs stayed skipped when the real build
succeeded. On a release pipeline that is a publish that quietly never
happens. The write now carries the same task_id guard the other two do.

The two sweeps also stopped sharing a conclusion. Zombie selects on a
runner that has gone quiet, which is what a lost task looks like; endless
selects on start time alone, and its runner is alive and has been
reporting for hours. That job is wedged, not lost, so re-queueing it only
spends hours more of a shared runner reaching the same wedge. Each sweep
now says which one it is holding.

The cap warning is driven by reaching the cap rather than by an in-memory
count that a lost update leaves raised, so it no longer reports failing a
job it did not fail.

Covers the re-claim race, the wedged job, the log, and the drop count
starting over on a rerun — the last so the whitelist clone that gives a
new attempt a fresh budget cannot quietly become a copy of everything.

Assisted-by: blue:claude-opus-5
2026-08-14 15:07:13 -07:00
..
2026-07-27 18:50:23 -07:00