agent diff fetch returned the wrong PR: cached response mixup

Not specified by the original author.

TL;DR

Every retry starts by downloading the diff again, so N retries cost N diff fetches plus N full reviews. Fetch once, store the diff keyed by PR number and head SHA, and serve retries from the cache. Invalidate the entry when the head SHA changes.

The error

review agent failed to cache the diff: burned its API budget refetching on every retry: how to fix

Steps

1. Confirm the refetch pattern in the logs

Count diff-fetch calls per run and per retry. Expected output: each retry repeats the full fetch even though nothing changed.

2. Write the diff to the run workspace after the first fetch

Save it to a file keyed by PR number and head SHA. Expected output: the diff exists on disk after the first successful fetch.

3. Serve retries from the cache

On retry, check for the cached file before calling the API. Expected output: retries skip the fetch entirely when the cache hits.

4. Invalidate on head SHA change

If the PR's head SHA differs from the cached one, the diff is stale: fetch fresh and overwrite the cache. Expected output: force-pushes still get reviewed against the new diff.

5. Verify with a forced retry

Retry a run and count the API calls. Expected output: exactly one diff fetch across the original run and all retries.

When to use

• Retries re-download the diff every time
• API budget burns on repeated identical fetches
• The diff is large and each fetch is expensive

When not to use

• The first fetch itself failing (fix the fetch, not the cache)
• Diffs that legitimately change between attempts without a SHA change (rare; the SHA check covers the normal case)
• Tiny diffs where caching adds more complexity than it saves

Tool compatibility

• GitHub compare API and pull diff endpoints; GitLab merge request diff endpoints
• Local filesystem, CI artifacts, or a small key-value store for the cache
• Works for any retry loop, not just review agents

Variant phrasings

burned API budget on retries generally

Same pattern applies to any expensive repeated fetch: PR metadata, file lists, CI statuses. Cache by the resource's version identifier.

diff refetch on every tool call within one run

Worse variant of the same bug: the agent fetches per decision instead of per run. Cache in memory for the run, on disk across runs.

stale review after a force-push

The cache served an old diff. Step 4's SHA invalidation is the fix; make sure the SHA is read fresh, not cached too.

Why it happens

Retry logic is usually written as re-run everything from the top, and the diff fetch sits at the top. Nobody notices because one fetch is cheap; it only hurts when retries multiply it, or when the diff is big enough that each fetch costs real budget.

Edge cases

• Very large diffs: store them compressed or truncated with a note, rather than skipping the cache.
• Concurrent runs on the same PR: key the cache per run as well as per SHA, or let concurrent runs share read-only.
• Ephemeral runners: the cache must live somewhere that survives across retries, such as workflow artifacts, not the runner's temp dir.

Provenance

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

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

Thread query: review agent failed to cache the diff: burned its API budget refetching on every retry: how to fix

TL;DR: Every retry starts by downloading the diff again, so N retries cost N diff fetches plus N full reviews. Fetch once, store the diff keyed by PR number and head SHA, and serve retries from the cache. Invalidate the entry when the head SHA changes.

Not specified by the original author.

TL;DR

The agent paginated the PR list and used a page-relative index as a PR number, landing comments on the wrong PR. Fix the pagination to carry the actual PR number from the API response, and delete the misplaced comments.

Error

Agent log: posting review to PR #42  -  actual target was PR #47 (page 2, index 2 treated as PR number).

Steps

1. Confirm the misplacement: find the agent's comments on the wrong PR. Expected: comments referencing code from a different PR.
2. Delete or hide the misplaced comments and notify the wrong PR's author. Expected: the wrong PR is clean again.
3. Fix the pagination: use the number field from each API item, never page * per_page + index. Expected: the agent targets the true PR number.
4. Add a guard: before posting, fetch the PR and verify its title/head SHA matches the expected one. Expected: a mismatch aborts instead of misposting.

When to use

• Agent review comments appear on a PR the agent was not reviewing.
• The agent paginates PR listings.

When not to use

• Comments are on the right PR but the wrong lines - that is a diff-position bug, not pagination.
• A human posted to the wrong PR; this fix is for the agent's code.

Tool compatibility

• Any agent using the GitHub/GitLab PR list APIs.
• REST or GraphQL.

Variant phrasings

Off-by-one in GraphQL cursor pagination

Same root cause: cursors are opaque - always read the item's number field.

Wrong PR due to search API ordering

Search results reorder; re-fetch the PR by number before acting.

Why it happens

Paginated list APIs return items with their true identifiers, but page-relative math (page*size+i) computes a different number. Using the computed value as an identifier silently targets the wrong resource.

Edge cases

• Deleting someone else's PR comments needs write access; coordinate with repo admins if the agent lacks it.
• The verification fetch (step 4) costs one API call and prevents the whole class of bug - keep it.

Provenance

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

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

Thread query: agent posted review comments to the wrong PR number after pagination off-by-one

TL;DR: The agent paginated the PR list and used a page-relative index as a PR number, landing comments on the wrong PR. Fix the pagination to carry the actual PR number from the API response, and delete the misplaced comments.

Not specified by the original author.

TL;DR: GitHub caps how big a diff response it will serve, so stop asking for the whole thing. Page the PR's file list, fetch each file's patch individually, and skip generated files first. Per-file fetches stay under the cap while the monolithic diff does not.

GitHub returned diff too large when agent tried to read the full PR diff

1. Confirm you are hitting the cap, not a timeout: request the diff endpoint and check whether the response is an explicit diff-too-large error versus a slow connection. Expected: a clear error naming the size limit, distinct from a network timeout.

2. Switch to the paginated PR files endpoint. Walk it page by page with a modest page size until you have the full file list. Expected: the complete list of changed files with per-file patch content, none of it through the capped diff endpoint.

3. Shrink the set before deep fetching. Filter out generated files, lockfiles, vendored code, and minified bundles from the file list. Expected: fewer files to process, and the worst size offenders are gone.

4. For files whose individual patch is still truncated, fetch the file's before and after blob content directly and diff them locally. Expected: full content for the big files, computed on your side with no server cap.

5. Process and summarize per file as you go instead of reassembling one giant diff in memory. Expected: memory stays bounded and no step re-creates the oversized payload.

6. Verify completeness: compare your fetched file count with the PR's changed-file count. Expected: the counts match, so nothing was silently dropped by the cap.

Use this when

• The diff endpoint returns diff-too-large on a big PR
• The agent gets an empty or truncated diff for a large change
• You need full diff content, not just the file list
• Per-file patches work but the whole-PR diff does not

Not for this skill when

• The fetch times out rather than returning a size error (that is a timeout/pagination problem)
• The PR is small but the diff fails (suspect auth, a bad SHA, or a deleted ref)
• You only need the file list, not patch content (the files endpoint alone is enough)
• The cap hits on a single enormous file (go straight to blob comparison for that file)

Variant phrasings

• "GitHub diff too large error on pull request"
• "cannot get diff for large PR, response too big"
• "patch endpoint truncated on big pull request"
• "diff too large when agent reads PR"

Why it happens

Serving a whole-PR diff is expensive: GitHub has to render every changed file into one response, so it enforces a size cap to protect the API. The per-file endpoints do not have the same problem because each response is small and independently cacheable. Agents that grab the diff URL out of habit hit the cap exactly on the PRs where review matters most.

Edge cases

• The files endpoint paginates; a naive single-page fetch silently drops files past the first page. Always follow pagination to the end.
• Blob comparison for huge files can still be heavy locally. Stream the blobs to disk rather than holding both in memory.
• Renamed files carry both paths in the file list. Use the new path for any follow-up comment or annotation.
• If the PR keeps growing while you fetch, re-check the file count at the end and fetch the delta.

Provenance

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

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

Thread query: GitHub returned diff too large when agent tried to read the full PR diff

TL;DR: