Repository navigation
Name the Claims holding Pickup at its Claim limit, and tell the Day shift once #787
Description
This was generated by AI during triage.
Problem
When a repository is at its Claim limit, every Pickup run logs only a count:
at the Claim limit on JacobStephens2/thirdshift: 3 open issue(s) labelled in-progress, pickup.limit is 3
On 2026-10-18/19 this held thirdshift pickup for over a day while Ready issue #88 waited. The three Claims (#740, #671, #667) each had a green pull request awaiting review (#767, #679, #743). That's the limit working as intended, but nothing outside cron.log said so, and the log line gives no clue what to review. From the count alone, an operator (and an agent asked to look) first took these for stale Claims.
Proposed behavior
- Name the holders. The skip message lists each claimed issue with its pull request and state, e.g.
held by #740 (PR #767 ready for review), #671 (PR #679 ready for review), #667 (PR #743 ready for review), plus the number of Ready issues waiting behind them. - Tell the Day shift once. When a Pickup run first finds the repository at its Claim limit with at least one Ready issue waiting, send one Run notification ("pickup held: N pull requests await review") and don't repeat it until the hold clears and comes back.
Decisions needed
- Where to keep the "already notified" state for (2) so it survives across scheduled invocations and stays consistent across two hosts (Two machines' Pickup runs can take the same Ready issue at once #712).
- Whether (2) should go through the existing email notification or wait for the Console (Spec: see, follow and Stop a machine's Commands from the CLI #711, make easy way to answer "are the pickup runs of thirdshift running on this host?" #744).
- Whether a Claim whose PR has been ready for review longer than some threshold should be named as such ("waiting 2d").
Validation targets
- The skip message names every holder with its PR number and state, plus the Ready issues waiting.
- Holding with no Ready issue waiting sends nothing.
- A held state sends exactly one notification across repeated passes, and another after it clears and recurs.
Related
#744 (is pickup running on this host?), #712 (two hosts' Pickup runs), #711 (Console).
Activity
JacobStephens2 commentedon Oct 21, 2026
Agent Brief
Category: enhancement
Summary: A Pickup run held at its Claim limit names the issues holding it
This brief covers this issue's first proposed behavior only. Pull request states, the count of Ready issues waiting and the one-time notification moved to #959.
Current behavior:
When a repository is at its Claim limit, a Pickup run is skipped with a reason that gives only a count, such as
at the Claim limit on <owner>/<repo>: 3 open issue(s) labelled in-progress, pickup.limit is 3. That reason reaches stderr, the Activity log (when it differs from the last one recorded), and the idle Passes inthirdshift statusand the Console. From the count alone, an operator can't tell which pull requests to review. One took them for stale Claims.Desired behavior:
The reason names each issue holding the limit, lowest number first. For example:
at the Claim limit on <owner>/<repo>: #924, #936 and #953 are labelled in-progress, pickup.limit is 3. The numbers come from the same read that counts the Claims, so the skip makes no extra GitHub requests. The Activity log writes a skip line only when its reason changes, so it now records a new line when the set of holders changes, and not otherwise.Key interfaces:
Skipped::AtClaimLimitand how it displays) and the gate that counts open issues labelledin-progress.thirdshift statusand the Console, which shows the latest skip reason.Acceptance criteria:
Out of scope: