At the per-person cap of ten live reservations a drain move refuses with exit 2 (the cap is not treated as contention), returns before writing its state so the judgement just answered is lost, and advises releasing a reservation, which would free an issue whose pull request is only waiting for a merge.

Frontmatter

.abcd/work/issues/resolved/iss-2610161015371794-at-the-per-person-cap-of-ten-live.md
open on GitHub ↗ · commit history ↗

References1

• itd-2610161016394967Drains on several accounts share the workrelated

mentions4

• dcn-26101610403643122026-10-16 — A drain waits when only held work is left (facilitator-on-delegation, drain-many-accounts): when the drain's holder is at the reservation cap, counted from the move's view before any reservation or judgement, or when every remaining eligible issue is held by others, the drain keeps its judgements, writes a waiting_until fifteen minutes on that is kept apart from the pace window, and names what it waits for (the holds, or the pull requests waiting to merge); it stops as empty only when no eligible issue is left, held or not (grounds: the drain already treats its pace window as a wait, and a bounded poll is the standard consumer wait; iss-2610161015371794, iss-2610161015422836).
• dcn-26101700183078692026-10-17 — A drain's wait at the cap and on held work is a look-again time, not a gate (facilitator-on-delegation, drain-many-accounts): a move before waiting_until still looks, since passing over held work in the move's view fetches and pushes nothing, takes any issue freed since, and keeps the time first written while the same wait stands, so polling early never pushes the wait out; the cap is counted in the move's view for the holder this copy reserves as, read with no network act (claim.ReaderHolder), and where only the forge could name that holder, the reservation act's own count refuses with the typed claim.CapError, which the drain reads as the same wait; the cap's refusal stays an ErrRefused refusal, so abcd reserve still exits 2 on it, and only its advice changes, to waiting for a pull request to merge; held work is an issue passed over because another holds it or a footprint it shares, while an issue handed back on origin or one this checkout already has a run for is a person's and never keeps the drain alive; and the drain's state keeps schema version 1, its waiting_until and waiting being added as steps 1 to 3 added origin_wait and pending_hand_backs (grounds: a bounded poll as the standard consumer wait, the drain's pace window as its existing wait, and a closed vocabulary for what the state names; spc-2610161044461448 step 6; iss-2610161015371794, iss-2610161015422836)
• iss-2610231004140527The live-reservation cap is counted per GitHub login across every session, copy and account that pushes under it (internal/core/claim/crowd.go), while each machine sets its own ceiling in reservation.max_live. On 2026-10-23 six interactive sessions on one login reached 30 live holds and abcd-43's reserve was refused at 10:40; abcd-ae raised the ceiling to 40 by hand, the third raise since 10-22 (hand-rolled coordination log, 10:40 and 10:41). A drain run under another account that pushes with the same login is counted against the same holder under its own, possibly lower, ceiling, which no session here can read, so the interactive sessions can hold the drain at its cap with nothing on either side saying so. Graded minor when filed, because the drain waits at the cap rather than failing (iss-2610161015371794), and whether the drain shares this login and at what ceiling is not yet confirmed; it was confirmed the same day, and the grade raised (below). This revisits the ruling recorded in iss-2610170717515674 (one ceiling per person, raised in the machine's configuration); related: iss-2610160925028248 (one reservation per record spends the cap) and iss-2610161457209287 (holds do not name their copy).
• spc-2610161044461448drain-many-accounts