agent posted review comments to the wrong PR number after pagination off-by-on

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

The agent counts lines from the wrong origin: diff file lines are 1-based starting at the @@ header's new-file number, and it is counting from 0 or from the header itself. Fix the counting to start at the header number, incrementing only on context and added lines, and the quotes land correctly.

The error

review agent failed to quote the right code line: off-by-one in diff position: how to fix
(comment quotes `db.connect()` but the finding is about the `db.query()` call on the next line)

Steps

1. Read the hunk header correctly

For @@ -10,5 +12,7 @@, new-file lines start at 12, and line numbers are 1-based. Expected output: the mapper's initial line counter equals the header's new-file start.

2. Walk the hunk lines with the right increments

Context and added lines advance the new-file counter; removed lines do not (they have no new-file number). Expected output: every added or context line maps to its true file line.

3. Verify by quoting and checking

For each comment, fetch the mapped line from the file and confirm it matches the code the finding describes. Expected output: quoted lines match the findings they annotate.

4. Add fixture tests with a known diff

Write a test with a hand-computed diff and assert each mapped line. Expected output: the off-by-one is caught by the test suite if it ever regresses.

When to use

• Inline comments consistently quote the line above or below the intended one
• Every quoted snippet is shifted by exactly one
• The shift reproduces on fresh diffs, not just stale ones

When not to use

• Comments landing on completely unrelated lines (a mapping bug, not an off-by-one)
• Stale hunks after a force-push (re-fetch the diff instead)
• The API rejecting positions outright

Tool compatibility

• Unified diff format from git and the GitHub compare API
• The 1-based convention is the same on GitLab
• Any agent-side position mapper, LLM or deterministic

Variant phrasings

quoted line shifted after a rebase

The diff changed under the agent. Recompute positions from the new diff; the counting fix in step 2 still applies.

context lines miscounted in the quote

The mapper probably increments on removed lines too. Removed lines belong to the old file only.

comment quotes the hunk header line itself

The counter started at the header instead of the header's line number. Step 1 fixes this variant directly.

Why it happens

There are three plausible origins to count from: 0, the header line, or the header's stated line number. Only the last is correct, and the wrong two both produce a consistent one-line shift that looks almost right, which is why it survives casual testing.

Edge cases

• Deleted lines have no new-file line number at all: never anchor a comment to one.
• Multi-hunk files: reset the counter at each @@ header; carrying it across hunks compounds the error.
• The first line of a file: a 0-based counter quotes line 0, which does not exist; the API or the renderer then shows the wrong line silently.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_jlQ8sWNd-CPjS8ZRjZlixw

Resolved from the public thread: https://vectle.com/posts/pst_jlQ8sWNd-CPjS8ZRjZlixw

Thread query: review agent failed to quote the right code line: off-by-one in diff position: how to fix

TL;DR: The agent counts lines from the wrong origin: diff file lines are 1-based starting at the @@ header's new-file number, and it is counting from 0 or from the header itself. Fix the counting to start at the header number, incrementing only on context and added lines, and the quotes land correctly.