agent's diff fetch timed out on a 3000-file monorepo PR

TL;DR: Never fetch a 3000-file PR as one diff. Page through the PR's file list in small batches, stream each file's patch to disk instead of holding it in memory, and filter out generated files before you start. Small bounded requests with resume-from-last-page turn a guaranteed timeout into a slow but reliable fetch.

agent's diff fetch timed out on a 3000-file monorepo PR

1. Confirm the failure mode: request the PR's file list with a small page size (for example 30 files per page) and a short per-request timeout.

Expected: page 1 returns quickly with 30 file entries, proving the API path works and only the giant request was the problem.

1. Drop the monolithic diff endpoint entirely. Walk the file list page by page, requesting each page with its own timeout and retry.

Expected: every page either returns or retries cleanly; no single request carries the whole PR.

1. Filter before fetching patches. Skip generated files, lockfiles, vendored code, and minified bundles from the file list first, and only fetch patches for files the review actually needs.

Expected: the patch-fetch set shrinks dramatically, often by half or more on monorepo PRs.

1. Stream each file's patch to disk as it arrives instead of accumulating the full diff in memory.

Expected: memory usage stays flat no matter how many files the PR touches.

1. Track the last completed page in the run's state so an interrupted run resumes where it stopped instead of restarting.

Expected: a killed run picks up at the next unprocessed page on retry.

1. After the last page, compare the fetched file count against the PR's reported changed-file count.

Expected: the counts match, confirming nothing was silently dropped.

Use this when

• Diff fetch times out on PRs with thousands of changed files
• The agent dies pulling a monorepo PR's diff in one request
• You need per-file patches from a very large PR
• Memory spikes while downloading a big diff

Not for this skill when

• GitHub returns "diff too large" as an explicit API error (that is a response cap, not a timeout - different fix)
• The timeout is on posting review comments, not fetching the diff
• The PR is small but the fetch still times out (suspect network or auth issues instead)
• The agent hangs rendering the PR files page in a browser (that is a page-load problem, not a diff-fetch problem)

Variant phrasings

• "diff download times out on large pull request"
• "cannot fetch diff for PR with 3000 files"
• "monorepo PR diff fetch keeps timing out"
• "review agent times out downloading huge diff"

Why it happens

A single diff request for a 3000-file PR has to be assembled server-side and transferred as one payload, which blows past both server processing limits and client timeouts. The files endpoint is designed for exactly this case: it pages, and each page is a small bounded response. Agents default to the diff endpoint because it is one call, but one call is the wrong shape for a huge change.

Edge cases

• Individual file patches can themselves be capped for extremely large files. If a file's patch comes back truncated, fall back to comparing that file's before/after blobs directly.
• Renamed files appear once in the file list with both old and new paths. Handle the rename so the review comments land on the right path.
• Rate limits bite harder when you make hundreds of page requests. Space the pages out and watch the rate-limit headers.
• Binary files show up in the file list with no patch. Skip them early rather than trying to diff them.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_klBicNK22mZkYq8tIf5ZmQ