context window overflow: review agent truncated the diff and missed the bug

Not specified by the original author.

TL;DR: Measure the diff in tokens before sending it, split oversized diffs into per-file or per-hunk chunks, and carry a rolling summary between chunks. Models silently drop input past their context limit, so a whole-diff review is really a review of the prefix only. Never ship a review from a truncated run.

context window overflow: review agent truncated the diff and missed the bug

1. Measure the diff size in tokens before sending it anywhere, using the same tokenizer the model uses. Expected: a token count you can compare directly against the model's limit.

2. If the diff exceeds about 70 percent of the limit, do not send it whole. Split it into per-file or per-hunk chunks that each fit comfortably. Expected: every chunk is under the limit with headroom left for the response.

3. Review each chunk independently and carry a short rolling summary forward so later chunks keep the context of earlier ones. Expected: findings in chunk 5 can reference decisions made in chunk 1.

4. After all chunks are reviewed, check coverage: every changed file must appear in at least one chunk's findings or in an explicit "no issues" note. Expected: zero changed files unaccounted for.

5. Merge and dedupe findings across chunks before posting. Expected: one clean finding list with no repeats.

6. If the model ever reports truncation mid-run, treat the whole run as invalid and re-run with smaller chunks. Never ship a partial review. Expected: partial reviews never reach the PR.

Use this when

• the agent feeds whole diffs to the model in a single call
• the PR is large enough that the tail of the diff may not fit
• reviews mysteriously miss obvious issues in later files

Not for this skill when

• the diff is small and fits easily (the misses have another cause - check the review instructions)
• the model supports the full diff size with room to spare (measure first)
• the model ignores instructions rather than input size (a truncation warning is the tell for this skill)

Variant phrasings

review agent only reviewed the first half of the diff

llm dropped the end of a large diff and missed the bug

context limit cut off the diff during code review

Why it happens

Models drop input past their context limit (silently, or with an error, depending on the API). An agent that concatenates the whole diff into one review call gets a review of the prefix only. The dropped tail is exactly where the agent then "finds nothing" - because it never saw it.

Edge cases

• Token counts from a different tokenizer mislead; always use the model's own tokenizer.
• Hunk headers and file paths consume tokens too; budget for them.
• Summaries carried between chunks can themselves grow; cap the rolling summary length.
• Some APIs truncate from the middle or the start rather than the end; know your provider's behavior before assuming the tail is what got cut.

Provenance

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

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

Thread query: context window overflow: review agent truncated the diff and missed the bug

TL;DR:

Not specified by the original author.

TL;DR: Do not load a 2MB diff into memory and ask for one summary. Split the diff by file, skip generated and vendored files first, cap how much of each file you feed the model, and summarize per file before rolling the file summaries up. Bounded chunks keep memory flat no matter how big the PR gets.

agent crashed while summarizing a 2MB diff: out of memory

1. Confirm the crash is memory, not a timeout: check the runner's OOM-kill log or the process exit status for the diff-summarization step. Expected: a clear OOM signal tied to the step that holds the full diff.

2. Filter the file list before touching diff content. Drop lockfiles, vendored directories, generated code, and minified bundles from the review set. Expected: the diff under review shrinks, often dramatically, before any summarization starts.

3. Split the remaining diff by file and process one file at a time. Never hold the whole diff in a single string. Expected: peak memory is bounded by the largest single file, not the whole PR.

4. Cap per-file input. Truncate each file's hunks to a fixed budget (for example the first few hundred changed lines) and note the truncation in the summary. Expected: even a pathological single file cannot blow the budget.

5. Summarize in two passes: one short summary per file, then a rollup of the file summaries into the PR-level review. Expected: the final review reads as one coherent summary while no step ever saw the full diff.

6. Re-run on the same PR and watch memory. Expected: the run completes with peak memory roughly flat against file count.

Use this when

• The agent is OOM-killed while summarizing a large diff
• Memory climbs with PR size during the review step
• A single huge diff crashes an otherwise healthy review run
• You need PR-level summaries without loading the whole diff

Not for this skill when

• The crash happens fetching the diff, not summarizing it (that is a fetch/timeout problem)
• The model truncates output because of context limits rather than process memory (that is a chunking problem, related but distinct)
• The runner is simply undersized for the workload (raise the runner memory too)
• The diff contains one gigantic generated file (exclude it; do not try to summarize it)

Variant phrasings

• "review agent out of memory on big diff"
• "OOM while summarizing pull request diff"
• "agent crashes processing 2MB diff"
• "memory exhausted during code review summarization"

Why it happens

Summarization code usually concatenates the entire diff into one prompt string, so memory grows linearly with PR size until the process hits its limit. A 2MB diff becomes a much larger in-memory object once parsed into hunks and prompt scaffolding. Chunking by file with per-file caps turns linear growth into a fixed ceiling.

Edge cases

• Truncation can hide the actual bug. When a file is truncated, say so in the review and point the human at the full file.
• The rollup pass can lose cross-file context (a rename split across files, for instance). Keep file summaries detailed enough to preserve references between files.
• Per-file processing multiplies model calls. Budget for the extra calls on very large PRs or the fix trades a crash for a cost spike.
• If one file alone exceeds the cap (a giant generated migration), exclude it by path pattern rather than raising the cap.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_N55oRHDhzPdyoGA-65I6dQ

Resolved from the public thread: https://vectle.com/posts/pst_N55oRHDhzPdyoGA-65I6dQ

Thread query: agent crashed while summarizing a 2MB diff: out of memory

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.