Review threads and reviews are capped at 50 per PR, so the inbox reports wrong counts

Not a duplicate of #21. That one is about SEARCH_QUERY capping each bucket at 50 pull requests. This is about the sub-connections inside DETAILS_QUERY, which cap the data within a single pull request. Different query, different failure, and this one produces wrong numbers rather than missing rows.

What happens

DETAILS_QUERY in src/main/github/queries.ts fetches reviews(last: 50), reviewThreads(last: 50) and comments(last: 50). No pagination. On a long-running pull request these caps bite, and they bite in the worst possible direction.

Review threads: the reason text starts lying

reviewThreads(last: 50) returns the 50 most recent threads regardless of whether they are resolved. Take a PR with 70 threads where the recent ones have mostly been resolved: the 50 that arrive are largely dead, and an older unresolved thread waiting on your answer never makes it into the payload at all.

unansweredThreads and threadsAwaitingMyReply in src/core/threads.ts then count what they were given, so "2 open threads" is shown when there are four — undercounting, always. And the forgotten old thread is precisely the one the feature exists to surface. A PR can even fall out of the inbox entirely this way, if every thread that would have put it there got trimmed off.

Reviews: the same trick, meaner

reviews(last: 50) feeds two different consumers (see computeLastMentionAt and the mapping in src/core/map-pr.ts):

• myLatestReview — which review is yours
• the mention scan — which reads bodyText from everyone's reviews

On a heavily-reviewed PR your own review can be pushed off the end. myLatestReview then returns null, hasParticipated says you never touched it, and classifyReviewPr files it under needs-review / "Review requested" as though you had never looked at it. The app tells you to do work you already did.

Proposed fix

Review threads — the connection takes no filter arguments (only first / last / after / before), so unresolved threads cannot be requested directly. Paginate: switch to forward pagination with pageInfo { hasNextPage endCursor } and follow pages up to a ceiling, or fetch a first page and only pay for more when it comes back full.

Reviews — the reviews connection does take an author argument, so the two consumers can be split into two aliased connections on the same node:

• reviews(last: 50) — unchanged, for the mention scan, where missing an old mention is a much smaller harm.
• myReviews: reviews(last: 5, author: $login) — exact, tiny, and makes myLatestReview correct no matter how busy the PR is.

That is a cheap and complete fix for the worse of the two symptoms. Worth confirming the argument against the current schema before building on it.

Note

Conversation comments(last: 50) has the same shape of problem but a much smaller blast radius — it only feeds the mention scan, where losing an old mention degrades gracefully. Probably fine to leave alone; noting it so nobody has to rediscover it.

Start in src/main/github/queries.ts and trace DETAILS_QUERY into src/core/threads.ts and src/core/map-pr.ts, including computeLastMentionAt and the review mapping. Confirm the current GitHub schema arguments, then inspect how pagination and aliased review connections can feed the existing consumers. Done means older unresolved threads and the user's own review are counted correctly on heavily reviewed pull requests.