- Shipped
- September 3, 2026 at 5:44 AM UTC
- Author
- Kamo
- Commit
- 310f3c0
The reaper added in 199e367e compared each container's commit against github.sha and KEPT the matches, on the theory that a matching sha meant "this run". That is wrong exactly when a run is re-triggered for the same commit: the stale build carries the same sha, so the guard protected the one container the step exists to kill. Caught it doing that. TASK-10531 (cancelled, 30 minutes in) and TASK-10532 (live) were both building 199e367e; 10532's reaper looked at 10531's orphan, saw its own sha, and kept it. Two builds again, and the reaper reported success. The correct rule is simpler than the one I wrote. At that point in the job our own buildx has not started, so every kamo-internal buildx on the host belongs to an earlier run, and the concurrency group permits exactly one. They are all superseded. Kill them all — no sha comparison, no age window, nothing to get subtly wrong. Still scoped to this image so kbservice and securityservice builds sharing the runner are untouched, and still keyed on the buildx process inside the container rather than the act container itself, whose command is `tail -f /dev/null`. Dry-run against the live runner before committing: reaps the kamo-internal build, skips the dictionary sync job.