agent review referenced a commit sha from a different PR

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

The agent fetched the base branch (or the merge-base) and reviewed that instead of the PR's head. Resolve the head SHA from the PR API and diff base...head explicitly before reviewing.

Error

Agent review discusses code from main that the PR never touched; none of the PR's actual changes are mentioned.

Steps

1. Confirm: compare the review's claims against the PR's files-changed list. Expected: the review describes base-branch code.
2. Fix the ref resolution: get head.sha from the PR API response and check out / fetch exactly that SHA. Expected: the agent sees the PR's code.
3. Compute the review diff as base...head (three-dot), not base..head - three-dot shows what the PR introduces. Expected: the diff matches the PR page.
4. Re-run the review. Expected: findings reference the PR's actual changes.

When to use

• The agent's review discusses code the PR did not change.
• The agent checks out code itself.

When not to use

• The review is on an old head SHA - that is staleness, not the wrong branch.
• The agent uses the API diff directly; check which ref the API call requested.

Tool compatibility

• Any agent that clones/fetches PR code.
• GitHub / GitLab.

Variant phrasings

Agent reviewed the merge commit

The merge commit includes base changes; review the head diff instead.

Fork PRs: agent fetched the wrong remote

Fork heads live on the fork remote - add it and fetch the PR ref explicitly.

Why it happens

Default clones and naive fetches land on the base branch. Unless the agent explicitly resolves the PR's head ref, it reviews whatever main points at - confidently describing code the author never wrote.

Edge cases

• Three-dot vs two-dot diff is the classic trap; three-dot is almost always what a review wants.
• For fork PRs, the head SHA may not exist on the base repo remote at all - fetch from the fork.

Provenance

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

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

Thread query: agent reviewed the base branch instead of the head ref

TL;DR: The agent fetched the base branch (or the merge-base) and reviewed that instead of the PR's head. Resolve the head SHA from the PR API and diff base...head explicitly before reviewing.

Not specified by the original author.

TL;DR

Snapshot the head SHA when the review starts and re-check it right before posting. If a force push moved the head, recompute the diff and remap every line number to the new head - or abort the post and re-run. Posting positions computed against the old commit is what puts comments on the wrong lines.

The problem

review agent failed to refresh line numbers after a force push: stale commit references: how to fix

When to use

• Inline comments appear on lines that do not match the code they quote
• GitHub instantly marks the agent's new comments as outdated
• A force push landed while the review was running
• The review API rejected comments with outdated diff hunk errors

When not to use

• The agent never computed diff positions (an off-by-one or position-mapping bug, not a staleness bug)
• Comments are on the right lines but the wrong files (a file-matching issue)
• The PR was not force-pushed and the head SHA never changed

Steps

1. Snapshot the head SHA at review start

gh pr view 123 --json headRefOid --jq .headRefOid | tee /tmp/review-head-sha.txt

Expected output: a 40-char SHA stored in the run metadata. Every position the agent computes is valid only against this SHA.

2. Re-check the head SHA immediately before posting

Read the current head SHA again and compare it to the snapshot. If it matches, post normally.

Expected output: a match (safe to post) or a mismatch, meaning a push landed mid-run and every computed position is suspect.

3. On mismatch, recompute the diff against the new head

git fetch origin pull/123/head
git diff OLD_SHA...NEW_SHA -- path/to/file.py

Expected output: the exact hunks the push changed, showing which findings still map and which need new positions.

4. Remap each finding to the new head or drop it

For findings in hunks the push did not touch, translate line numbers through the hunk offsets and post against the new commit id. For findings inside rewritten hunks, re-derive the position from the new diff; if it cannot be mapped, drop the finding and note it in the summary.

{
  "body": "nit: rename for clarity",
  "commit_id": "NEW_HEAD_SHA",
  "path": "src/app.py",
  "line": 42,
  "side": "RIGHT"
}

Expected output: every posted comment carries the new head SHA with verified positions; unmappable findings are withheld instead of misplaced.

5. If the push rewrote most of the diff, re-run instead of remapping

When more than a handful of findings fail to map, abort and re-run the review against the new head. Expected output: a clean review on current code instead of remapped guesses.

Tool compatibility

• GitHub REST review comments API: commit_id, path, line, and side must all describe the same head; works on github.com and GHES.
• gh CLI 2.x: pr view --json headRefOid for SHA snapshots.
• Review agents that post inline comments: keep the snapshot-and-recheck pattern regardless of which client library posts.

Variant phrasings

review comments marked outdated immediately after posting

Almost always a stale head SHA. Add the step-2 recheck; if pushes are frequent, shorten the gap between position computation and posting.

force push invalidated the review positions

Same fix. For repos with heavy force-push traffic, consider the quiet-period gate from the moving-target guide so reviews start on settled heads.

inline comment quoted the wrong line after a push

When the comment text is right but the anchor line is wrong, the mapping step (step 4) was skipped. Remap through the new hunks instead of reusing old line numbers.

Why it happens

Inline comment positions are only meaningful relative to a specific commit. A force push replaces the analyzed commit with a new one, so earlier line numbers point at different code - or at lines that no longer exist. The mapping was done correctly, just against a commit that is no longer the head.

Edge cases

• Rapid successive pushes: re-check in a loop until the SHA is stable, or give up after three attempts.
• Comments posted before the push were correct when posted; leave them.
• Renamed files in the push: path-based remapping fails; match by content similarity or drop the finding.
• Multi-commit PRs without force push: new commits appended normally do not invalidate old positions, only rebases and force pushes do.

Provenance

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

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

Thread query: review agent failed to refresh line numbers after a force push: stale commit references: how to fix

TL;DR: Snapshot the head SHA when the review starts and re-check it right before posting. If a force push moved the head, recompute the diff and remap every line number to the new head - or abort the post and re-run. Posting positions computed against the old commit is what puts comments on the wrong lines.