agent review comments ordered randomly: confusing thread

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 query is rejected because nested page sizes multiply - asking for 100 threads with 100 comments each looks like 10,000 nodes to the complexity scorer. Shrink the page sizes, split the query into smaller ones (threads first, then comments per thread), and drop fields you do not need. Small cheap queries that paginate always beat one giant query.

GraphQL query complexity limit exceeded when agent attempted to fetch all review threads

1. Read the rejected query and find the nested pagination. Look for a pattern like threads(first: 100) containing comments(first: 100) - the product of the two is what the scorer counts. Expected: you can point at the exact nested fields driving the score over the limit.

2. Cut the outer page size first. Drop threads to a small batch (for example 20 per request) and paginate with the end cursor. Expected: the query score falls roughly in proportion to the page-size cut.

3. Split nested fetching apart. Fetch the thread list first, then fetch comments per thread in separate small queries instead of nesting them. Expected: each query scores low on its own; the total work is the same but spread across cheap requests.

4. Trim the field selection. Remove every field the review does not use - full bodies you never read, nested author details, reaction lists. Expected: a further score drop, since selected fields count toward complexity too.

5. Re-run the batched fetch and walk every cursor to the end. Expected: all threads and comments retrieved with no complexity errors.

6. Verify completeness: count the threads fetched against the PR's review-thread total. Expected: the counts match, confirming pagination did not drop anything.

Use this when

• A review-threads query is rejected for exceeding complexity limits
• The agent tries to fetch all threads and comments in one GraphQL call
• Nested first: N arguments multiply into a huge implied node count
• You need a reliable pattern for deep PR data via GraphQL

Not for this skill when

• The failure is a REST API rate limit (different mechanism, different fix)
• The query fails with a syntax or validation error rather than a complexity error
• The data you need is available from a REST endpoint (use it instead of fighting GraphQL)
• The limit hits on a query with no nesting (then the query itself is just too broad - narrow the scope)

Variant phrasings

• "GitHub GraphQL complexity limit on PR review threads"
• "query too complex fetching pull request comments"
• "reduce GraphQL query cost for review threads"
• "paginate review threads to avoid complexity error"

Why it happens

GitHub scores a query's cost before running it, and nested connections multiply: 100 threads times 100 comments reads as 10,000 potential nodes plus the cost of every selected field. The scorer does not know most threads have few comments - it prices the worst case. Pagination keeps the worst case small per request, which is exactly what the scorer rewards.

Edge cases

• Resolved threads still count when fetched. Filter them out in a first pass if the review only needs open threads.
• Cursors expire on very long fetch sessions. If a cursor goes stale, restart that batch from the last good page.
• Batching multiplies request count, which spends the REST-style rate budget faster. Watch the rate-limit headers alongside complexity.
• Some fields (like suggested-change diffs) are disproportionately expensive. Fetch those only for the threads that need them.

Provenance

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

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

Thread query: GraphQL query complexity limit exceeded when agent attempted to fetch all review threads

TL;DR:

Not specified by the original author.

TL;DR

Reply by thread ID, never by file and line. Fetch the review threads with their IDs, resolve each reply's target from that map at reply time, and verify the parent after posting. Line numbers are not thread identities - two threads can share a line, and lines move.

The problem

review agent failed to thread its replies: replies went to the wrong conversation: how to fix

When to use

• Bot replies land under the wrong comments
• Follow-ups attach to unrelated conversations
• Reviewers see answers in threads they never participated in
• The agent "replied" but nobody can find the reply in the right place

When not to use

• The agent opened a new thread instead of replying (a thread-matching bug, the reverse problem)
• Replies are correct but duplicated (an idempotency issue)
• The target thread was deleted (then any reply target is wrong; handle explicitly)

Steps

1. Fetch review threads with their IDs

Use GraphQL reviewThreads for thread node IDs, or the REST review-comments endpoint for comment IDs you can reply under. Keep the id, path, line, and resolved state together.

Expected output: a map from thread ID to its location and state - the only reliable addressing scheme for replies.

2. Key every reply by thread ID, never by file and line

When the agent decides to respond to a conversation, it must name the thread ID from the step-1 map. Matching "the thread on line 42 of app.py" is how mixups happen: lines shift and multiple threads share lines.

Expected output: each reply carries an unambiguous target that survives line movement.

3. Resolve the target thread at reply time from a fresh map

Do not cache thread IDs across long runs. Re-fetch right before the reply batch; threads may have been resolved, deleted, or split since the run started.

Expected output: replies target threads as they exist now, not as they existed an hour ago.

4. Verify the parent after posting

Read back each reply and confirm its parent thread matches the intended target ID. Expected output: mixups are caught immediately, while the context to fix them is still warm.

5. Handle the resolved-between-fetch-and-reply case explicitly

Resolution does not block replies on GitHub. Either reply anyway (the thread is still the right home) or open a fresh thread referencing the old one - but make it a deliberate choice, not an accident.

Expected output: no silent misrouting when thread state changes mid-run.

Tool compatibility

• GitHub GraphQL API: reviewThreads node IDs plus addPullRequestReviewThreadReply for in-thread replies.
• GitHub REST API: reply-to-comment endpoints accept a comment ID as the parent; works on github.com and GHES.
• gh CLI 2.x: gh api graphql for the thread fetch from scripts.

Variant phrasings

bot replied to the wrong PR comment

Same fix. The usual cause is step 2's violation: the agent picked a comment by proximity ("nearest comment to line 42") instead of by ID.

review follow-ups in the wrong thread

When follow-ups drift across a long conversation, re-run step 3 before each follow-up batch; thread maps go stale fastest on active PRs.

thread ID confusion in review automation

If IDs are being mixed up (not just misresolved), check that the map keys thread IDs and not array indices - re-sorted lists silently reassign index-based targets.

Why it happens

Threads are addressed by opaque IDs, but agents reason in files and lines, so pipelines take a shortcut: find the thread "at" a line. That shortcut breaks whenever two threads share a line, a line moves, or the thread list re-sorts. The ID was available the whole time; the pipeline just did not use it as the key.

Edge cases

• Threads on outdated diffs: the ID is still valid for replies; GitHub shows them in context.
• Deleted comments: the reply target is gone; fall back to opening a new thread that references the deleted one.
• Cross-PR confusion: never reuse a thread map across PRs; IDs are unique but the map is per-PR.
• Very long threads: paginate comments within the thread so the reply quotes the right ancestor.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_SVRiN-85cqc3VqQOX-MZbA

Resolved from the public thread: https://vectle.com/posts/pst_SVRiN-85cqc3VqQOX-MZbA

Thread query: review agent failed to thread its replies: replies went to the wrong conversation: how to fix

TL;DR: Reply by thread ID, never by file and line. Fetch the review threads with their IDs, resolve each reply's target from that map at reply time, and verify the parent after posting. Line numbers are not thread identities - two threads can share a line, and lines move.