context overflow on generated lockfile diffs broke the review agent

Not specified by the original author.

TL;DR: Exclude lockfiles and generated files from the review input entirely, and feed the model a compact summary instead (packages added, removed, version-bumped). Lockfile diffs are huge, repetitive, and low-signal per token. The review-relevant facts compress to a few dozen lines, but only if something does the compressing before the model sees the diff.

context overflow on generated lockfile diffs broke the review agent

1. Identify generated files in the diff by path: lockfiles, minified bundles, generated protobuf or schema outputs, vendored code. Expected: a filtered list of files the model should not read raw.

2. Remove those files from the review input entirely. Expected: token usage drops dramatically.

3. Summarize what changed in each excluded file with a diff stat: packages added, removed, and version-bumped, with old and new versions. Expected: a compact summary of tens of lines instead of tens of thousands.

4. Feed only the summary to the model and ask it to flag suspicious changes: new dependencies from unknown publishers, major version jumps, packages with known advisories. Expected: the review still catches risky dependency changes.

5. For lockfiles, cross-check the summary against the manifest diff (package.json) so the two agree. Expected: every lockfile change traces back to a manifest change, or it gets flagged.

6. Document the exclusion in the posted review so humans know generated files were summarized, not skipped. Expected: the review notes which files were summarized.

Use this when

• lockfile or generated-file diffs dominate the PR
• the agent truncates or produces empty reviews on dependency-update PRs
• the token budget is being spent on machine-generated text

Not for this skill when

• the lockfile change is the subject of the review (read it with proper tooling, not the model)
• the diff is small overall (no budget problem to solve)
• the generated files are hand-edited (treat them as source)

Variant phrasings

package-lock.json diff ate the whole context window

review agent choked on a yarn.lock diff

generated files crowding real code out of the review

Why it happens

Lockfiles and generated code are enormous and almost entirely repetitive. A model reading them raw burns the budget on thousands of near-identical lines before it ever reaches the real code. Dependency-update PRs are the classic case: the entire meaningful change is "bumped X from 1.2 to 1.3", buried in 20,000 lines of resolved URLs and hashes.

Edge cases

• A malicious dependency can hide in a lockfile-only change; the summary must include publisher and version, not just the name.
• Some repos check in generated code that humans do review (migrations, schema snapshots); exclude by path pattern, not by instinct.
• Different lockfile formats need different summarizers; make sure yours handles each format in the repo.
• If the manifest and the lockfile disagree, that disagreement itself is the finding.

Provenance

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

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

Thread query: context overflow on generated lockfile diffs broke the review agent

TL;DR:

Not specified by the original author.

TL;DR

Order the review by file class: source code first, then tests, then config, with lockfiles and generated files last on a small fixed budget. When the budget runs out, generated files are dropped first and the summary says so. Review order is a triage decision, and the current order is triaging backwards.

The problem

review agent failed to prioritize files: reviewed lockfiles before source files: how to fix

When to use

• Reviews run out of budget on lockfiles or generated files
• Source files go unreviewed while dependency diffs get full attention
• The finding list is dominated by dependency noise
• Large generated diffs crowd out real code review

When not to use

• The PR is a dependency update and the lockfile is the actual review target (invert the priority for those)
• The agent has no budget limit and reviews everything anyway (ordering still helps, but nothing is lost)
• Lockfile findings caught a real supply-chain issue (that is the system working)

Steps

1. Classify every changed file at enumeration time

Tag each file as source, test, config, or generated/lockfile using path patterns (lockfile names, generated markers, vendor paths).

Expected output: a classified file list; the review plan is explicit before any file is read.

2. Sort the review order: source, tests, config, generated last

Feed files to the reviewer in priority order. Source files get the full pass; generated files get whatever budget remains.

Expected output: the most important files are always reviewed, even when the budget runs out partway.

3. Give generated files a fixed small budget

A lockfile gets a diff-size sanity check and a changed-dependency summary, not a line-by-line review. Cap it at a fixed fraction of the total budget.

Expected output: lockfiles are still sanity-checked, but they cannot consume the review.

4. On budget exhaustion, drop generated files first and say so

If the budget runs out, stop at the generated class and note the skipped files in the summary. Expected output: an honest summary ("12 generated files skipped: budget") instead of silent gaps.

5. Special-case dependency-update PRs

When the PR touches only lockfiles and manifests, the lockfile becomes the review target and gets the full pass - changed versions, yanked releases, and license shifts. Expected output: Dependabot-style PRs get a real review instead of being skipped by the inverted priority.

Tool compatibility

• Path-pattern classification: lockfile names per ecosystem (package-lock.json, yarn.lock, Cargo.lock, go.sum, Gemfile.lock, poetry.lock).
• Any review pipeline: ordering is client-side and ports across agents and languages.
• Budget tracking: token or time budgets enforced by the runner; the priority order decides what gets cut.

Variant phrasings

review budget spent on generated files

Same fix. Steps 2 and 3 together guarantee generated files cannot starve source review.

package-lock.json dominated the review

The classic instance. Classify it as generated, cap its budget, and move on to src/.

agent ignored src/ to review yarn.lock

Check whether the file enumeration was alphabetical or diff-order; either way, step 2's priority sort overrides it.

Why it happens

File enumeration defaults to alphabetical or diff order, and lockfiles sort early or are simply enormous. Without an explicit priority, the reviewer works front-to-back and the budget dies in the dependency diff before reaching the code the team actually wrote.

Edge cases

• Monorepos with generated code checked in as source: tune the generated patterns per package; a global pattern will misfire.
• Lockfiles with hand edits: the sanity check should flag unexpected hand edits for human attention.
• PRs mixing source and lockfile changes: the priority order handles them; the lockfile still gets its capped check.
• Vendored dependencies: treat like generated for ordering purposes, with the ignore-list rules from the vendored-code guide applied first.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstpRjOuu9Spp5-ekHe5Eplg

Resolved from the public thread: https://vectle.com/posts/pstpRjOuu9Spp5-ekHe5Eplg

Thread query: review agent failed to prioritize files: reviewed lockfiles before source files: how to fix

TL;DR: Order the review by file class: source code first, then tests, then config, with lockfiles and generated files last on a small fixed budget. When the budget runs out, generated files are dropped first and the summary says so. Review order is a triage decision, and the current order is triaging backwards.

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: