A build's reservation lapses while the host waits on an agent, because only implement step renews it (renewReservation in internal/core/implement/loop/reservation.go): build itd-82's run-2610260500113538 reserved itd-82 until 07:00Z, its implementer then held the implement stage for about thirteen hours under the shared machine's load gate, and no step ran to renew it. Revived after the lapse, the reservation is judged like a new one (crowd.go), and a build's automated act backs off on any overlap with the same person's other copy, so the renewal was refused for loop.go, in the footprint of iss-2610142134353345, live from the main checkout. The run goes on to validation holding no reservation, and the land fence will stop it, though nothing of the other record's work touches the lane's files.

Frontmatter

.abcd/work/issues/resolved/iss-2610261837062463-a-build-s-reservation-lapses-while-the.md
open on GitHub ↗ · commit history ↗

mentions7

• dcn-26102913525120582026-10-29 — iss-2610261837062463 renews a build's reservation wherever its agent waits, not only at implement step. The gated waiter (implement load --wait and --race-gate) renews, at once and every five minutes while it waits and while its command runs, each due reservation of a run in progress that lives in the checkout the waiter runs in, or whose lane worktree is that checkout (found through git worktree list), through the loop's own renewal under the run lock, so a lapsed one is revived as step revives it; a run whose lock another invocation holds is skipped, since that invocation is a step that renews it. implement status renews a due reservation of each run it shows before rendering, and its help no longer says it writes nothing. A lapsed revival is judged for overlap with the same person's other copy against the files the lane's branch changed, as the landing's narrowing reads them, not the run's whole footprint; it keeps its whole footprint, an overlap with another person still backs it off on the whole footprint, and where the changed files cannot be read the whole footprint is judged, as before.
• dcn-26102919255082862026-10-29 — iss-2610261837062463: a lapsed revival narrows its own-copy overlap check to the lanes' changed files only once no lane is still at or before its implement stage and no spec step is pending; otherwise it judges the whole footprint and backs off, because an implementer's uncommitted edits are invisible on the branch tip and two automated lanes must never edit one file. The waiter and implement status also leave a run parked at land alone, as the drain does, and re-read the reservation view under the run lock so one lapse is renewed once.
• dcn-26102922381914962026-10-29 — iss-2610261837062463: a lapsed revival narrows its own-copy overlap check to the lanes' committed changes only when every lane is past all editing: handed back, at land, or at validate awaiting reviewers alone, with no implementer awaited (a fix round), no sync conflict pending and no spec step pending. Any other lane, held ones included, makes the revival judge the whole footprint, since an implementer's edits stay uncommitted until its receipt. The waiter waits, bounded, for a renewal round in flight before it exits, so a pushed renewal is logged.
• dcn-26103004224814862026-10-30 — iss-2610261837062463: a lane at validate is never past editing, since one verdict hands a fix implementer any file of the footprint; a lapsed revival narrows only when every lane is done, discarded, handed back, or at land with no sync pending, and a lane sent back from land to editing has the run's own-copy overlap judged again on the whole footprint, as an issue run's leaving land already is. The waiter waits at most a few seconds for a renewal round in flight when its command exits, well inside the gate's settle hold, because a waiter lingering on a slow push reads as queued and holds every other gate on the machine; a pushed renewal left unlogged costs one record line, and the next round reads the fresh tip.
• dcn-26103006154516592026-10-30 — iss-2610261837062463: when a lane leaving land cannot fetch the reservations to re-judge its other-copy overlap, the step waits as for an outage, the way fetching the default branch does (netFailure), rather than refusing for a person; a view that cannot be read after a good fetch refuses the step. An issue run's lapsed revival at land narrows to its changed files as the landing's renewal does, and only an intent run keeps its whole footprint and names the other copy's reservation it went past.
• iss-2610142134353345The role gates on the reviewer route's digest compare, in receipt (loop.go) and in verifyValidation (validate.go), are redundant and unreachable: no validator but a ruthless or security reviewer reaches the compare, so removing both leaves every test green.
• itd-82`abcd drain` fixes the issues that need no decision, and hands the rest back by kind