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.

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