agent posted review comments to the wrong PR number after pagination

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

Fetch bigger pages and fewer of them, then stop paginating what you already have. Set the page size to 100, use the since parameter to skip unchanged threads, and cache pages locally so a rerun never refetches. One GraphQL query can often replace the entire pagination loop.

Verbatim error

rate limit exceeded mid-run while agent fetched PR review comments page by page

Steps

1. Maximize page size. Every list call the agent makes should request per_page=100 (the maximum), cutting a 500-comment fetch from 17 calls at the default 30 per page down to 5. Expected: the same data arrives in roughly a third of the API calls.

2. Skip what has not changed. Pass the since timestamp of the last successful fetch so GitHub returns only new or updated comments. Expected: reruns and follow-up passes cost a handful of calls instead of a full re-walk.

3. Cache pages to disk keyed by PR number and page, with the response ETag. On rerun, send the ETag; a 304 response costs nothing against the limit. Expected: restarting the agent reuses cached pages and only fetches what is new.

4. Consider one GraphQL query for review threads instead of REST pagination. A single pullRequest { reviewThreads(first: 100) { ... } } call returns threads with comments inline. Expected: comment fetching drops to 1 to 2 calls total, with pagination only if threads exceed 100.

Use this when

• An agent paginates PR comments or reviews and hits the rate limit.
• You need to cut REST API calls for comment fetching.
• A rerun of the agent refetches everything from scratch.

Not for this skill when

• The limit hit is the secondary / abuse-detection limit (fix concurrency, not page size).
• Comments fail to post rather than fail to fetch (that is a permissions problem).
• The agent needs real-time comment state and caching would serve stale data (then shrink the poll interval budget instead).

Variant phrasings

• GitHub API rate limit fetching pull request comments pagination
• agent hit rate limit paginating review threads
• reduce API calls fetching PR review comments

Why it happens

Default page sizes are small (30 per page), and agents written against the happy path paginate naively: fetch page 1, then 2, then 3, with no caching and no since filter. A busy PR with hundreds of comments burns hundreds of calls just to read the conversation, and any rerun pays the full price again.

Edge cases

• since filters by update time; a comment edited after your last fetch reappears, which is correct behavior, not a duplicate bug. Dedupe by comment id.
• GraphQL review threads cap at 100 per query without nested pagination. Very large PRs still need cursor loops, but far fewer calls than REST.
• Deleted or outdated-diff comments still count in pagination. Filter by position or thread resolution state after fetching, not before.
• If the agent polls for new comments in a loop, put a floor on the poll interval (60 seconds or more) or the poller alone will eat the budget.

Provenance

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

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

Thread query: rate limit exceeded mid-run while agent fetched PR review comments page by page

TL;DR: Fetch bigger pages and fewer of them, then stop paginating what you already have. Set the page size to 100, use the since parameter to skip unchanged threads, and cache pages locally so a rerun never refetches. One GraphQL query can often replace the entire pagination loop.

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.