review agent's replies went to the wrong review conversation: thread ID mixup

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.

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

List every review thread - including resolved ones - before posting, and fingerprint each new finding against them. If a matching thread exists, reply in it or skip the finding; only open a new thread when a fresh push actually invalidated the old discussion. Most duplicate threads happen because the agent never looked at the resolved threads.

The problem

review agent failed to check resolved state: opened a duplicate review thread: how to fix

When to use

• Two threads discuss the same issue on the same lines
• The bot re-raises a point a human marked resolved
• Reviewers complain the bot is "not reading the room"
• Thread count grows on every bot run without new code changes

When not to use

• The agent posted the same finding twice in one review (a within-run dedupe bug, not a thread-matching bug)
• The old thread is on an outdated diff and the new push changed that code (a new thread is correct there)
• Threads are duplicated by humans, not the bot

Steps

1. Fetch all review threads, resolved included

{
  repository(owner: "OWNER", name: "REPO") {
    pullRequest(number: 123) {
      reviewThreads(first: 100) {
        nodes { id isResolved path line originalLine comments(first: 5) { nodes { body } } }
      }
    }
  }
}

Expected output: the full thread list with resolved flags. Note the REST review-comments endpoint does not surface resolved state, so GraphQL is the reliable source here.

2. Fingerprint each new finding

Build a fingerprint from the file path, the nearest anchor line, and a hash of the normalized finding text (lowercased, whitespace-collapsed, code quotes stripped).

Expected output: a compact key per finding that matches the "same issue" even when wording differs slightly.

3. Match fingerprints against open and resolved threads

Compare each finding's fingerprint to the thread list from step 1, checking both open and resolved threads. Expected output: a hit list showing which findings already have a conversation.

4. Reply or skip on a match, with one exception

On a match: if the thread is open, reply in-thread; if resolved and the code is unchanged since, skip the finding. The exception: if a newer push touched those lines after the thread was resolved, the old discussion is stale and a new thread is legitimate.

Expected output: zero duplicate threads; every bot comment either extends an existing conversation or starts a genuinely new one.

5. Record thread IDs the run touched

Store the thread node IDs the run replied to or opened in the run metadata. Expected output: the next run can distinguish "I already handled this thread" from "this is new" without re-matching everything.

Tool compatibility

• GitHub GraphQL API: reviewThreads with isResolved is the canonical thread source; stable on github.com and GHES.
• GitHub REST API: fine for posting replies once you have the thread or comment ID, but not for resolved-state discovery.
• gh CLI 2.x: use gh api graphql -f query=... to run the step-1 query from scripts.

Variant phrasings

bot re-litigated a resolved review thread

Same fix. Pay special attention to the step-4 exception: if the code genuinely changed, re-raising is correct behavior and suppressing it would hide a regression.

duplicate review threads on the same lines

When the threads are on identical lines but different topics, tighten the fingerprint to include the finding's subject, not just path and line.

review agent ignored existing conversations

Usually the agent only fetched unresolved threads. Flip the default: fetch resolved too, and treat "resolved" as "handled" unless the code moved.

Why it happens

Agents typically fetch only open review comments to keep context small, so resolved threads are invisible to them. When the agent then "discovers" the same issue, it opens a fresh thread. The information needed to avoid the duplicate existed the whole time; the agent just never asked for it.

Edge cases

• Outdated-but-resolved threads: GitHub keeps them visible; only treat them as handled if the current diff still contains the discussed code.
• Threads on renamed files: path matching fails; fall back to matching on the finding-text hash.
• Very long PRs: paginate reviewThreads past the first 100; duplicates hide on page two.
• Human reopened a resolved thread mid-run: re-fetch threads right before posting, not just at run start.

Provenance

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

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

Thread query: review agent failed to check resolved state: opened a duplicate review thread: how to fix

TL;DR: List every review thread - including resolved ones - before posting, and fingerprint each new finding against them. If a matching thread exists, reply in it or skip the finding; only open a new thread when a fresh push actually invalidated the old discussion. Most duplicate threads happen because the agent never looked at the resolved threads.