agent re-reviewed unchanged files after every push: wasted budget loop

Not specified by the original author.

TL;DR

Compare file content, not commit SHAs: after a rebase, compute per-file blob SHAs on both heads and re-review only the files whose content actually changed. Carry prior findings and approvals forward for everything else. A rebase that touches nothing should cost nothing.

The problem

review agent failed to skip already-approved files after a rebase: wasted budget: how to fix

When to use

• A rebase triggers a full re-review with no content changes
• Force-pushes with identical trees redo all review work
• Findings get re-posted after history rewrites
• Review budgets spike on repos with rebase-heavy workflows

When not to use

• The rebase resolved conflicts and file contents changed (re-review is correct)
• Files were renamed with modifications (content changed; review them)
• The previous review never completed (there is nothing to carry forward)

Steps

1. Resolve both heads and list changed files between them

git diff --name-only OLD_HEAD_SHA NEW_HEAD_SHA | tee /tmp/rebase-changed.txt
wc -l /tmp/rebase-changed.txt

Expected output: the file list the rebase actually touched. Empty output means a pure history rewrite with zero content change - the whole re-review can be skipped.

2. Compare per-file blob SHAs, not commit SHAs

For each file, compare the blob hash at the old head versus the new head. Only files whose blob changed need re-review; identical blobs mean identical content regardless of the new commit SHAs.

Expected output: a short list of truly-changed files, usually a fraction of the PR.

3. Carry prior findings and approvals forward

For unchanged files, re-attach the previous run's findings and approval state, marked as carried forward rather than re-reviewed. Do not re-post their comments.

Expected output: the review state after the rebase equals the state before it, minus only the files that changed.

4. Supersede stale comments only for changed files

Dismiss or update old inline comments solely on files whose content changed. Leave comments on unchanged files alone.

Expected output: no comment churn on files the rebase did not touch.

5. Record the (old-head, new-head) pair

Store the pair in the run metadata. If the same rebase is seen again (repeated force-push of the same tree), it is a no-op. Expected output: idempotent handling of repeated rebases.

Tool compatibility

• git CLI: diff --name-only and blob comparisons between any two SHAs; works everywhere.
• GitHub review APIs: dismissing or updating stale comments per file; github.com and GHES.
• gh CLI 2.x: for fetching head SHAs and managing review comments.

Variant phrasings

full re-review after force push with no changes

Same fix. Step 1 alone often resolves it: an empty changed-file list short-circuits the entire run.

wasted review budget on rebase

Track budget per run and tag runs triggered by rebases; the step-2 blob comparison is what converts them from full cost to near-zero.

findings re-posted after history rewrite

The carry-forward in step 3 plus per-file supersede in step 4 stop the re-posting without losing the review history.

Why it happens

Review pipelines key their "already reviewed" state on commit SHAs. A rebase replaces every commit SHA even when file contents are byte-identical, so the pipeline concludes nothing was reviewed and starts over. Content addressing (blob SHAs) instead of commit addressing fixes the identity confusion.

Edge cases

• Conflict resolution during rebase: blobs change, correctly triggering re-review of those files only.
• Renamed files: match by content hash across the rename so a pure rename does not trigger a full re-review.
• Partial rebases (some commits rewritten): the blob comparison handles this naturally; only rewritten content re-reviews.
• Squash-merge after rebase: the final squash is a new tree; review the squash result once, keyed on its tree SHA.

Provenance

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

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

Thread query: review agent failed to skip already-approved files after a rebase: wasted budget: how to fix

TL;DR: Compare file content, not commit SHAs: after a rebase, compute per-file blob SHAs on both heads and re-review only the files whose content actually changed. Carry prior findings and approvals forward for everything else. A rebase that touches nothing should cost nothing.

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

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.