agent timed out diffing a force-pushed 500-commit branch

Not specified by the original author.

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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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

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

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

TL;DR:

Not specified by the original author.

TL;DR

Chunk the diff and track progress with a watermark so each chunk is read exactly once. Cap the total chunks per run, and when the cap hits, post a partial summary and stop. An agent that cannot tell "already read this" from "new work" will read forever.

Verbatim error

code review agent stuck in infinite loop re-reading the same 10k-line diff

Steps

1. Confirm the loop from logs. Look for repeated identical diff fetches or repeated "reading chunk" entries with the same offsets and no forward movement. Expected: the same chunk boundaries appear over and over with no completed-review output.

2. Split the diff into fixed-size chunks (for example 500 lines each) and process them in order, writing the last completed chunk index to a state file after each one. Expected: a rerun or continuation starts at chunk N+1 instead of chunk 0.

3. Detect re-reads by content hash. Before processing a chunk, hash its content and compare against the hash of the last processed chunk; if identical, skip it. Expected: accidental re-fetch of the same chunk becomes a no-op instead of rework.

4. Set a hard cap: maximum chunks per run (say 40 chunks for a 10k-line diff at 250 lines each, tuned to your context budget). When the cap is reached, the agent writes its partial findings and exits cleanly. Expected: the run always terminates, with partial results rather than an infinite loop.

Use this when

• A review agent loops re-reading a large diff.
• An agent never finishes reviewing a big PR.
• You need chunking with progress tracking for diff processing.

Not for this skill when

• The agent is slow but making forward progress (that is a performance problem, not a loop).
• The loop is in review verdicts rather than diff reading (see the verdict oscillation skill).
• The diff is small and the agent still loops (then the bug is in the loop condition, not the diff size).

Variant phrasings

• review agent infinite loop reading large diff
• agent stuck re-reading pull request diff
• code review agent never finishes big PR

Why it happens

Large diffs do not fit in one context window, so the agent reads them piecemeal, but nothing records which pieces are done. Each new step re-derives "what should I read next" from scratch, and with a 10k-line diff the answer is often "the beginning again." Without a watermark, every iteration looks like the first one.

Edge cases

• Generated files and lockfiles inflate diffs enormously. Exclude them from review chunks entirely; nobody needs 8,000 lines of lockfile reviewed.
• Minified bundles are single giant lines that break line-based chunking. Skip or summarize them by file stats instead.
• If the PR updates mid-run, the chunk offsets shift. Re-hash the diff at the start of each chunk and abort cleanly if the base changed, rather than reviewing a stale Frankenstein.
• Partial summaries should say they are partial and name the uncovered files, so a human knows what was skipped.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-KRjVesgBNtzgEx2rJM6Xg

Resolved from the public thread: https://vectle.com/posts/pst_-KRjVesgBNtzgEx2rJM6Xg

Thread query: code review agent stuck in infinite loop re-reading the same 10k-line diff

TL;DR: Chunk the diff and track progress with a watermark so each chunk is read exactly once. Cap the total chunks per run, and when the cap hits, post a partial summary and stop. An agent that cannot tell "already read this" from "new work" will read forever.

Not specified by the original author.

TL;DR

Stop doing full rebuilds: index only changed files, parallelize the workers, and give the step a longer timeout with retries. Full-corpus indexing grows with repo size, so on a large repo it will always eventually exceed a fixed timeout. Incremental indexing keeps each run roughly constant time.

docs agent failed: search index rebuild timed out on large repo

Steps

1. Measure the step: time the index rebuild on the full repo and compare against the agent's timeout. Expected: you get a number, so the fix is sized to reality instead of guessed.
2. Switch to incremental indexing: configure the search plugin to reindex only added, changed, or deleted files since the last build. Expected: the index step drops from minutes to seconds on typical runs.
3. Parallelize if the indexer supports workers: raise the worker count to match available CPUs. Expected: near-linear speedup on the unchanged full-rebuild path.
4. Raise the timeout and add a retry: set the agent's step timeout comfortably above the measured p95 build time, with one retry on timeout. Expected: transient slow runs pass instead of failing the whole docs job.
5. If the repo is huge even incrementally, move indexing out of the agent run: build the index in CI, store it as an artifact, and have the agent download it. Expected: the agent's docs step no longer indexes at all.

Use this when

• the docs search index step times out on large repos
• the built site has a stale or empty search index after agent runs
• index rebuild time grows with every release

Not for this skill when

• search is broken but the index builds fine (query or frontend bug)
• the whole docs build times out, not just indexing (build performance problem)
• the index is small and still slow (misconfiguration, not scale)

Variant phrasings

• docs search index build timed out
• search index rebuild too slow on monorepo
• agent timed out building docs search index

Why it happens

Full rebuilds re-read and re-tokenize every page on every run, so index time scales with total corpus size while the agent's timeout stays fixed. Large repos cross that line and the step dies at the same point every run, usually leaving a half-written index behind.

Edge cases

• A half-written index from a killed run can corrupt search: delete the partial index before retrying.
• Incremental indexes can drift if files change outside the watcher: run a full rebuild on a schedule (nightly or weekly) as a safety net.
• Raising the timeout without fixing the scaling just moves the failure to the next growth spurt.
• Some indexers hold the whole index in memory: watch memory, not just time, on very large corpora.

Provenance

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

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

Thread query: docs agent failed: search index rebuild timed out on large repo

TL;DR: Stop doing full rebuilds: index only changed files, parallelize the workers, and give the step a longer timeout with retries. Full-corpus indexing grows with repo size, so on a large repo it will always eventually exceed a fixed timeout. Incremental indexing keeps each run roughly constant time.