[Bug]: PullRequestSyncReactor sweeps send the same linked PRs many times over, so one sweep costs 16-100 GraphQL calls instead of ~7 #18295

Before submitting

• I searched existing issues and did not find a duplicate. [Bug]: PR detail/activity is re-fetched for every displayed PR on each focus, visibility change and 5-minute tick (merged PRs included), exhausting the GitHub GraphQL quota #13496 is about renderer re-fetches on focus. [Bug]: PR sync reads pull requests GitHub cannot find on every sweep, even on settled threads #17799 is about NOT_FOUND links on settled threads. This one is about the server-side sweep itself, with every link reachable and open.

Area

apps/server: PullRequestSyncReactor / pull request summary batching (GitHub CLI integration)

Version

T3 Code (Alpha) 0.0.45, macOS, a single desktop client and no remote clients connected.

Setup

• About 156 open pull requests linked across 9 active threads, all on github.com and all reachable by the server's credential. None are stale or NOT_FOUND, which I checked against the REST API.
• Default settings. sidebarAutoSettleAfterDays is null and every thread was active the same day.

What I measured

1. In server.trace.ndjson, 389 of ~420 GitHubGraphQlBudget.query spans over 16 minutes sat under PullRequestSyncReactor.syncGroup within sweep. Per sweep:

   sweep start	duration	groups	GraphQL calls
   1	65 s	159	16
   2	278 s	159	56
   3	79 s	159	100
   4	18 s	183	55
   5	57 s	160	92

   With 25 aliases per PullRequestSummaries call, 159 groups should take about 7 calls.

2. From outside the app, sampling the gh api graphql … PullRequestSummaries child processes gave 234 calls in 4 minutes. They carried 25 aliases each and covered only 158 distinct PRs, so each PR was read about 37 times in 4 minutes. A 30-minute sample averaged ~40 calls/min, about 2400/h.

3. Cost is 1 point per call (rateLimit { cost }). That is ~48% of the account's 5000/h GraphQL budget, and with other tools on the same account the budget ran out.

Expected behavior

One sweep reads each due linked PR once, which is about ceil(due PRs / 25) GraphQL calls a minute.

Possible causes (unverified)

• DETAIL_CACHE_CAPACITY = 128 is smaller than the number of linked open PRs. With LRU eviction a full sweep may evict its own entries, so later reads in the same sweep or the next one miss the cache.
• SUMMARY_BATCH_WINDOW (10 ms) can be missed under load when reads first go through the persisted cache and lock, which splits a sweep into many batches.
• executeRaw counts were above GraphQlBudget.query counts in two sweeps (109 vs 100, 116 vs 92). That may mean per-PR fallback reads after a failed batch, but the "batched pull request summary read failed" debug line did not appear.

Impact

Agent workflows that poll GitHub on the same account get rate-limited. There is no setting to lower the PR sync rate. The interval is hardcoded, and auto-settle doesn't help while threads are active.

Workaround

None, apart from archiving threads.