[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

[eowca]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web pull request views + apps/server PullRequestService / GitHub CLI integration

Steps to reproduce

1. Use T3 Code with several threads whose PRs appear in the UI (linked PRs, PR tabs or panels opened at some point). Keep a second client connected if possible, e.g. the web UI served over Tailscale.
2. Leave the app open and switch focus to and from the window every few minutes, as you normally would while working.
3. Watch the GitHub GraphQL budget: gh api graphql -f query='{rateLimit{remaining resetAt}}'.
4. Count GitHubCli.execute spans in ~/.t3/userdata/logs/server.trace.ndjson*, grouped by their ws.rpc.* ancestor.

Expected behavior

PR detail and activity reads are cached and shared across clients. A merged or closed PR is not re-fetched on every focus change. Refreshing should back off before the user's GitHub quota runs out, not only after (github requests to github.com are paused until the rate limit resets).

Actual behavior

Each client re-requests pullRequests.detail and pullRequests.activity for every PR it shows. This happens on window focus (after 10 s), on visibilitychange, and every 5 minutes while the user is active (the refresh hook with ya=3e5/1e4 in PanelLayoutControls). Merged PRs are included.

Measured on one machine (trace data plus rateLimit sampling):

• Bursts of ~120 gh calls every 3–4 minutes. In one 7-minute window, 822 of 881 T3 gh calls came from ws.rpc.pullRequests.detail (264 RPCs) and ws.rpc.pullRequests.activity (192 RPCs). gh pr view --json author,comments,reviews,commits paginates, so this averaged ~3 GraphQL points per call.
• GraphQL went from 4,974 to 2,206 remaining in 6.5 minutes. The 5,000/h budget ran out three times in one afternoon. Every other consumer combined made 66 GraphQL calls in 40 minutes.
• Two connected clients (desktop window and a Tailscale-served web tab) each refreshed the same PRs independently.
• Unlinking 70 merged PRs from active threads did not shrink the bursts. Of the 39 PRs in one burst, 18 were not linked to any thread; several of those match t3.pullRequests.detail:* entries in the client's localStorage.

This is a different path from #3581/#5673, which fixed per-branch gh pr list polling.

Impact

Major degradation or frequent failure

Version or commit

t3code 0.0.42-workspace-guard.1 (desktop AppImage), gh 2.101.0

Environment

Linux 7.0 (Ubuntu), desktop app plus a second web client via tailscale serve

Logs or stack traces

ws.rpc.pullRequests.activity -> PullRequestOperationError: Pull request operation activity failed: github requests to github.com are paused until the rate limit resets.

Workaround in use: a gh wrapper earlier on the server's PATH. For calls whose parent is the T3 server, it caches pr view --json and aliased pullRequest(number:) GraphQL reads for 10 minutes, or 24 hours once a PR is merged or closed. With it, later bursts of ~125 calls cost ~9 points instead of ~350.

[juliusmarminge]

Triage

Verdict: Bug, still present on main (d5d48742c9). Focus, visibility, and the five-minute tick re-read pull request detail from GitHub, and activity reads for every pull request still on screen or viewed in the last five minutes go out on the same refresh signal. Merged and closed pull requests are included. The fifteen-second server cache does not cover that cadence, so two clients each pay. This is not #3581 or #5673.

What the report gets right

useLiveRefresh is the hook behind the minified 3e5 / 1e4 constants. The interval is five minutes, the minimum gap is ten seconds, and it stops after six minutes without a click, key, or scroll. It runs on window focus, on visibilitychange, and on that interval while the window is visible (apps/web/src/hooks/useLiveRefresh.ts).

The open pull request panel calls it and forces pullRequests.detail:

  useLiveRefresh(
    () => {
      detailQuery.refresh();
    },
    { key: `pull-request:${environmentId}:${pullRequestKey}` },
  );

refresh() ignores the client’s sixty-second stale time. The server then keeps detail and activity for fifteen seconds (DETAIL_CACHE_TTL in PullRequestService.ts). A focus return after that is a cache miss. The pull requests page uses the same hook to re-read the list.

Activity is gh pr view --json author,comments,reviews,commits (PULL_REQUEST_ACTIVITY_JSON_FIELDS). That is the paginated read in the trace. The focus hook does not call activity itself. The panel refetches activity when that pull request’s updatedAt changes, and both detail and activity atoms subscribe to pullRequests.subscribeRefreshes. A turn checkpoint (CheckpointReactor → refreshAfterTurn), a mutation, or an explicit invalidate bumps the project epoch, drops the cache key, and tells every still-alive detail and activity atom to read again.

Those atoms stay alive for five minutes after the view unmounts (Atom.setIdleTTL on the query and on the writable wrapper in packages/client-runtime/src/state/pullRequests.ts). Open right-panel tabs subscribe for longer: each pull request tab without a linked snapshot mounts pullRequests.detail for its icon (RightPanelTabs.tsx). Unlinking a thread does not drop those atoms or tabs. t3.pullRequests.detail:* in localStorage is the snapshot written after a successful detail read so the panel can paint before the next RPC. It is not what schedules the fetch. A pull request that was opened, then unlinked, still matches that key and can still be in the burst.

Merged pull requests are not special on this path. The background link sync already skips a pull request once every linked copy is merged (PullRequestSyncReactor.ts, isDue), and a summary already held as merged is served without another host read. Detail and activity do not do that. Unlinking seventy merged pull requests would not shrink these bursts.

Two clients of one server do not share the refresh. In-flight identical reads coalesce, and the fifteen-second cache is what the “two people opening the same page” comment is about. Focus timers and five-minute ticks are much further apart than that, so each client’s burst misses and runs gh again.

The pause error is real. GitHubCli.execute for pr view checks GitHubGraphQlBudget before the process starts, and the message github requests to github.com are paused until the rate limit resets is SourceControlRateLimitPausedError. The preflight that feeds that budget is gh api rate_limit with GraphQL cost hardcoded to 1, and it replaces a cost learned from a real query whenever remaining has fallen. gh pr view never reports its own cost. A burst that starts above the ten-percent floor can spend about three points per call, more when gh paginates, while the budget subtracts one. That matches the quota going from 4,974 to 2,206 in a few minutes and later hitting zero, with the pause landing after the budget is already gone.

Why #3581 and #5673 are a different path

#3581 is background gh pr list per branch. #5673 stopped that amplification. Both are closed. Link sync now batches summaries and does not walk merged links every minute. The trace parent spans here are ws.rpc.pullRequests.detail and ws.rpc.pullRequests.activity.

Still on main

origin/main is d5d48742c9. The two commits after this checkout are Codex protocol only. Package version on main is 0.0.42. The reported build is 0.0.42-workspace-guard.1. Nothing newer in the nightlies changes this refresh policy. There is no open duplicate that describes this detail/activity focus loop.

What a fix has to change

Keep a shared server cache that actually covers the focus and five-minute cadence, and do not bump every pull request on a project into a host read just because one turn checkpointed. Stop re-reading detail and activity once the pull request is merged or closed. Count the real GraphQL cost of gh pr view so the ten-percent reserve trips before the quota hits zero. The localStorage snapshot can stay. It is only paint.

Workaround

The gh wrapper already in use matches the missing policy: cache pr view --json and pullRequest(number:) reads for about ten minutes, and for much longer once the pull request is merged or closed. Closing pull request tabs, and leaving the pull requests page, drops the mounted readers. Unlinking threads does not.

Disposition

Leave #13496 open. Add bug. Do not close it as a duplicate of #3581 or #5673.