Development record
The live-reservation cap still counts one total per GitHub login across every account that pushes as it, while each machine reads its own reservation.max_live, so a drain on another account under the same login stays held at its own ceiling whenever this machine's sessions hold more. iss-2610231004140527 made that visible: abcd peers counts the reader's holds by copy and warns from four fifths of this machine's ceiling, and the cap refusal groups the held records by copy. Whether the count itself should change is a ruling the coordinator is taking to the product thinker: keep one ceiling per person (the ruling recorded in iss-2610170717515674) or count per account and machine.
The live-reservation cap still counts one total per GitHub login across every account that pushes as it, while each machine reads its own reservation.max_live, so a drain on another account under the same login stays held at its own ceiling whenever this machine's sessions hold more. iss-2610231004140527 made that visible: abcd peers counts the reader's holds by copy and warns from four fifths of this machine's ceiling, and the cap refusal groups the held records by copy. Whether the count itself should change is a ruling the coordinator is taking to the product thinker: keep one ceiling per person (the ruling recorded in iss-2610170717515674) or count per account and machine.
Frontmatter
| id | iss-2610231127555243 |
|---|---|
| type | issue |
| lifecycle | open |
| severity | minor |
.abcd/work/issues/open/iss-2610231127555243-the-live-reservation-cap-still-counts.md
open on GitHub ↗ · commit history ↗
mentions2
- iss-2610170717515674The reservation cap (MaxLive, 10, in internal/core/claim/crowd.go) counts every live reservation one person holds across all of their sessions and copies, so one person running seven sessions on one account hit it all night: a session's fix waited for slots, two drain issues went unreserved, and sessions released and re-took holds to make room.
- 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).