Development record
The 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).
The 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).
Severity raised to major, 2026-10-23
Both unknowns were settled the same day. The drain pushes as the same login: its reservation of iss-2610120138028442 is authored and committed under it. Its ceiling cannot be read from this account, because the drain account's configuration is readable only by its owner. The drain had opened no pull request since 10-22, with five of its preflight waiters queued. So the interactive sessions of one login can hold the drain at a ceiling none of them can see, and neither side is told. That breaks the parallel-accounts arrangement abcd is being made to run, so the coordinator graded it major: it is fixed before the next cut, not deferred. The fix splits in two. The warning half needs no ruling and goes first: peers lists each live hold's session and copy, and warns when a holder is at its own ceiling or any it can read. The per-account count waits on the ruling the remedy names, which is going to the product thinker.
Grounds
- pursued: a person at or near the shared total now sees it, and which copy holds what, before a drain on the same login stalls unseen; shown wrong if a session reaches the cap with no warning in peers, or a sibling's hold reads as elsewhere
Frontmatter
| id | iss-2610231004140527 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | major |
.abcd/work/issues/resolved/iss-2610231004140527-the-live-reservation-cap-is-counted-per.md
open on GitHub ↗ · commit history ↗
mentions7
- dcn-26102723522496012026-10-27 — Peers-cap review notes deferred past its landing (lane D, facilitator on delegation, 2026-10-27): the rebased review pair of fix/peers-cap-warning returned LAND-WITH-NITS from both reviewers with no blocker. Its one display gap, the ceiling's note missing from the text form, is fixed on the branch. Three notes are captured and deferred to a follow-up change: iss-2610272352153282 (one sibling named two ways), iss-2610272352168723 (clashing sibling names merged) and iss-2610272352179242 (the cap refusal drops the listing note and labels copies without a holder filter). Grounds: none changes a count, a refusal or a reservation, only how a hold's copy is named; peers-cap resolves the major that blocks the release (iss-2610231004140527); and the first needs one worktree listing shared with the default branch's sibling naming, a refactor across both that wants its own review rather than a fifth round on this one.
- iss-2610120138028442The implement loop's merged check (internal/core/implement/loop/land.go, landMerged) asks the forge twice per poll while a pull request is not merged: `gh pr view --json state`, then prMergeability's `gh pr view --json mergeable,mergeStateStatus`. Both fields come from one view, so each poll spends two forge calls where one would answer, against the same rate limit the loop's other waits share.
- iss-2610160925028248abcd reserve holds one record per reservation and caps a person at ten live reservations across every session and copy of that account, so a small documentation pull request that fixes N records spends N of the ten: on 2026-10-16 two four-record follow-up PRs plus two intents another session held filled the cap, and every further reservation by any session of that person was refused until those PRs merged. The cap meant to bound one person's holds instead bounds how many record-sized fixes can be in flight.
- iss-2610161015371794At 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.
- iss-2610161457209287A person's reservations do not say which of their sessions or checkouts holds them. Several sessions run under one account, and every hold reads holder <the product thinker's login> with an opaque copy key. On 2026-10-16 two live intent holds (the messaging and cloud-sessions intents) sat at the ten-reservation cap while no session could tell whose they were. Two peers had to ask each other in turn before one was released.
- 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-2610231127555243The 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.