The inbox can silently drop pull requests past 50 per search bucket

What happens

SEARCH_QUERY in src/main/github/queries.ts asks for search(query: $q, type: ISSUE, first: 50) and there is no pagination anywhere — collectIds in src/main/github/fetch-prs.ts runs one such search per bucket and takes whatever comes back. Once a bucket matches more than 50 open PRs, everything past the 50th is dropped, quietly.

buildSearchQuery sorts by updated-desc precisely so the truncation is predictable (the freshest activity survives), and its doc comment says as much. Predictable is not the same as harmless.

Why it matters

Pullover's whole pitch is the negative case: "if a PR shows up, it's waiting on you; if it doesn't, you're free." A silent cap turns that into a lie for exactly the people the app is aimed at — the ones reviewing enough to need an inbox. involves:@me is the bucket most likely to blow past 50, since it matches authoring, assignment, mentions and commenting, which for an active reviewer accumulates across every PR they ever touched.

Worse, the failure is invisible: no banner, no count, no log. A PR that needs you just isn't there.

Proposed solutions

1. Paginate the search (the real fix)

Follow pageInfo { hasNextPage endCursor } on each bucket search up to a sane ceiling — say 200 ids per bucket — instead of stopping at the first page. Costs extra round trips and rate limit, but only for people who actually have that many PRs. The detail fetch downstream already batches ids in chunks of 25 (DETAIL_BATCH_SIZE), so nothing else needs to change to absorb a bigger id set.

2. Make 50 go further (cheap mitigations, worth doing regardless)

• Exclude archived repositories — see the archived-repos issue. Dead PRs currently eat live slots.
• Add a recency window, e.g. updated:>=<90 days ago>. A PR nobody has touched in three months is not waiting on you today, and it is exactly the kind of thing padding out involves:@me.

These shrink the problem but do not remove it, so they are not a substitute for pagination.

3. Surface the truncation (the honesty floor)

If a bucket search comes back with exactly the page limit, we know we may have missed something. Say so — a small banner in the popup along the lines of "showing the 50 most recently updated; some pull requests may be missing". Even with pagination in place this is worth keeping for whatever ceiling we land on, because the alternative is breaking the app's core promise without telling anyone.

Recommendation

Do 1 and 3 together; take 2 as free wins along the way.

Start with SEARCH_QUERY in src/main/github/queries.ts and collectIds in src/main/github/fetch-prs.ts, then trace how the popup receives search results. Account for pageInfo pagination up to the chosen ceiling and preserve the existing DETAIL_BATCH_SIZE batching. Done means searches no longer silently stop at the first 50 results and the popup surfaces possible truncation.