2026-10-16 — A drain takes its judgement hold on an issue once per request and never renews it on a poll; a request whose hold lapses unanswered is dropped, the hold released, and the issue asked again only after the drain's other eligible work, since judgement requests had no expiry of their own and a host that kept polling held the issue indefinitely (spc-2610161044461448 step 2).

Frontmatter

.abcd/work/decisions/dcn-2610161315385888-a-drain-takes-its-judgement-hold-on-an.md
open on GitHub ↗ · commit history ↗

mentions4

• dcn-26101614203143132026-10-16 — A drain does not ask a lapsed judgement request's issue again in the move it lapsed in, nor before a cool-down of the take-over margin (five minutes) from the move that dropped it, and then only after its other eligible work; that move releases the lapsed hold at once, every push a drain makes for a judgement is its hold except a renewal of this person's own live reservation, and a lapse is forgotten once its issue is asked again or answered. This refines dcn-2610161315385888: with no other work the tombstone and a new reservation landed in one move, so no other account ever had a window (spc-2610161044461448 step 2).
• dcn-26101618264435242026-10-16 — A yes whose hand-back a move cannot publish keeps it pending in the drain's state and publishes it over the issue's next release on origin (facilitator-on-delegation, drain-many-accounts review round): when the hold the yes would release has moved on (this person renewed or reserved the issue again by hand, another took it over, a person released it), when the drain took none because this person held the issue live from this copy, or when the release did not reach origin, the route says the hand-back is not yet published and why, the drain keeps it (pending_hand_backs: issue, kind, the blob the yes was judged over, why, when) and carries it into the next drain, and each later move whose view shows the issue's tip as a tombstone marking no hand-back publishes it as that tombstone's child, fenced on the tombstone and on the judged blob; a tip already marking a hand-back, a record finished or changed on origin's default branch, or one origin holds in no one file ends it with nothing published. The drain never releases a person's own reservation to publish it, so it waits for the person's release rather than taking the issue (grounds: dcn-2610161040365515, dcn-2610161806433529, dcn-2610161315385888; spc-2610161044461448 steps 2 and 3; the review of steps 1 to 18).
• dcn-26101618265579102026-10-16 — A drain move that has done anything writes it before it refuses, and says whether the answer given was taken (facilitator-on-delegation, drain-many-accounts review round): every refusal and error after the judgement block, the outage read, the merged-lane cleanup, a lane's routing, the run listing, the origin check, the judgement's reservation and its request, goes through refuseMoved, which writes the state a live drain holds first and then takes the judgement awaited as written as the one whose hold the move's clean-up keeps, so a hold the written state no longer records is released; a refusal after an answer was taken says it is not to be given again, and one met routing a yes before anything was taken says to give it again (grounds: dcn-2610161315385888; spc-2610161044461448 steps 2 and 9; the review of steps 1 to 18).
• spc-2610161044461448drain-many-accounts