fix(server): background PR sync reads summaries in batches

[juliusmarminge]

Stacked on #13189.

Problem

Every minute, PullRequestSyncReactor runs one gh pr view for each open linked pull request, and each run is a GraphQL call against the shared 5000/h budget. The traces put this loop at most of the fleet's spend: about 1900 calls/h on cups and about 1345/h on nucbox-1. While this PR was being opened, the budget ran out entirely ("API rate limit already exceeded").

Fix

• GitHubPullRequestCli.getPullRequestSummary now goes through an Effect RequestResolver.
  • Concurrent reads on the same host and credential (pinned credential fingerprint and rate-limit scope) are combined into one aliased GraphQL query of up to 25 pull requests.
  • The query reads the fields the thread snapshot needs, with checks as the head commit's rollup enum.
  • A 10 ms batch window lets the sweep's reads gather after each one's cache check.
• Fallbacks:
  • A pull request the batch answered nothing for, or a selector GraphQL cannot address, is read on its own with gh pr view, as before.
  • If the whole batch fails, each pull request is read on its own, except when the failure is a rate-limit pause.
• The reactor sweep's concurrency goes from 8 to 25, so one sweep's reads on a host land in the same batch.
• Other callers of summary (thread overview and so on) go through the same resolver. A single read costs 10 ms of latency and is otherwise unchanged.

Estimated savings

These come from the same trace-derived counts as #13189. They assume the linked PRs are spread over a few hosts and credentials, so a sweep of N PRs costs about ⌈N/25⌉ calls.

Machine	Sync gh pr view calls/h now	After batching
cups	~1900	~80–100
nucbox-1	~1345	~60–80
mbp / macmini	small	small

On top of #13189, the fleet should drop from about 3200 calls/h to roughly 400–500 calls/h. Each batched query should still cost about 1 GraphQL point, since its nested connections are small.

Verification

• vp test run on GitHubPullRequestCli.test.ts, gitHubPullRequestJson.test.ts, PullRequestSyncReactor.test.ts, GitHubPullRequestProvider.test.ts and PullRequestService.test.ts: all pass.
• New tests cover:
  • two concurrent reads sharing one aliased request, filed back by position;
  • a PR the batch skipped falling back to gh pr view;
  • the decoder skipping null or undecodable aliases, and reading merged state, bot authors and the checks rollup.
• The server typecheck has no errors.

Done by Claude Opus 5.5 in Claude Code (T3 Code).

🤖 Generated with Claude Code

---

Summary by CodeRabbit

• Performance
  • Pull-request summaries are retrieved more efficiently, especially when several summaries come from the same host. Background sync can also process more groups at once, helping updates complete sooner.
• Reliability
  • If a batched summary is unavailable, the system falls back to retrieving that pull request individually, helping preserve summary availability.

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ No successful main baseline artifact is available yet. This run establishes the initial measurement.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	—	13.5 KiB	—	15.1 KiB	✅
Codex	Thread snapshot wire	—	7.1 KiB	—	7.3 KiB	✅
Codex	Live turn WebSocket wire	—	6.4 KiB	—	7.8 KiB	✅
Codex	Live turn WebSocket decoded	—	56.2 KiB	—	66.4 KiB	✅
Codex	Live turn messages	—	9	—	21	✅
Claude	Total thread wire	—	13.5 KiB	—	15.1 KiB	✅
Claude	Thread snapshot wire	—	7.1 KiB	—	7.3 KiB	✅
Claude	Live turn WebSocket wire	—	6.4 KiB	—	7.8 KiB	✅
Claude	Live turn WebSocket decoded	—	57.0 KiB	—	66.4 KiB	✅
Claude	Live turn messages	—	9	—	21	✅

Baseline: unavailable · PR result: ec1440f · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 114.0 KiB
• Claude decoded thread snapshot: 114.6 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

🟡 Medium pullRequest/gitHubPullRequestJson.ts:1859

latestReviews(first: 20) drops reviews beyond the first 20, so when reviewDecision is null, toReviewDecisionWithReviews computes the status from an incomplete set and can persist the wrong approving or changes-requested status for pull requests with more than 20 reviewers. Fetch the complete review connection (including pagination) before using it as the fallback.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/server/src/pullRequest/gitHubPullRequestJson.ts around line 1859:

`latestReviews(first: 20)` drops reviews beyond the first 20, so when `reviewDecision` is null, `toReviewDecisionWithReviews` computes the status from an incomplete set and can persist the wrong approving or changes-requested status for pull requests with more than 20 reviewers. Fetch the complete review connection (including pagination) before using it as the fallback.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — The PR materially changes production GitHub-read scheduling by introducing grouped GraphQL batching, fallback reads, and higher sync concurrency rather than making a small isolated fix. It also adds a line-level static-analysis suppression, while an unresolved Medium finding flags incomplete review pagination that can affect persisted review status.

Not approved because:

• 1 blocking correctness issue found at or above your repo's Minimum Blocking Severity

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}