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

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.

Not specified by the original author.

TL;DR

The agent retried a review submission after a timeout, and both attempts landed. Make review submission idempotent: generate one idempotency key per review and dedupe on it, or check for an existing identical review before posting.

Error

PR #520 shows two identical reviews from review-agent[bot], posted 40 seconds apart.

Steps

1. Confirm the duplication: the two reviews have identical bodies and close timestamps. Expected: a retry, not two separate analyses.
2. Delete the duplicate review. Expected: one review remains.
3. Add idempotency: create a key from (PR number, head SHA, review content hash) and store it; skip posting if the key was already submitted. Expected: retries never create a second review.
4. Alternatively, list existing reviews before posting and skip when an identical body already exists. Expected: the same dedupe without extra storage.

When to use

• The same agent review appears twice on one PR.
• The agent retries on timeouts or errors.

When not to use

• Two different reviews (different content) - that is intended behavior, not duplication.
• A human double-submitted; this fix targets the agent's retry logic.

Tool compatibility

• GitHub / GitLab review APIs.
• Any review agent with retries.

Variant phrasings

Double-posted inline comments

Same fix at comment level: dedupe by (file, line, body hash).

Duplicate reviews after a crash-restart

Persist the submitted-review keys so restarts do not resubmit.

Why it happens

Review submission is not idempotent server-side: a retried POST after a timeout creates a second review because the first one actually succeeded. Without a client-side key, at-least-once delivery means duplicate reviews.

Edge cases

• Content-hash dedupe must normalize whitespace, or trivial formatting differences defeat it.
• Keep the idempotency window bounded (e.g. per head SHA) so legitimate re-reviews after new commits still post.

Provenance

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

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

Thread query: agent double-posted the same review: missing idempotency key

TL;DR: The agent retried a review submission after a timeout, and both attempts landed. Make review submission idempotent: generate one idempotency key per review and dedupe on it, or check for an existing identical review before posting.

Not specified by the original author.

TL;DR

The agent posts a fresh summary on every run without checking whether it already posted one. Make the summary idempotent: look for the bot's existing comment via a marker line, update it if found, and only create a new one if it is absent.

The error

review agent failed to dedupe: double-posted its summary comment after a retry: how to fix
(two identical "Review summary" comments from the bot on the same PR)

Steps

1. Give the summary a marker

Start the comment body with a distinctive first line the agent can search for, such as ## Review summary [bot-managed]. Expected output: every summary the bot posts is identifiable later.

2. List existing comments before posting

On each run, fetch the PR's comments and filter by the bot author plus the marker line. Expected output: the agent knows whether a summary already exists.

3. Update instead of create

If the marker is found, PATCH the existing comment with the new body. Only POST when no marked comment exists. Expected output: one summary comment that reflects the latest run.

4. Test the retry path

Trigger a retry on a test PR and confirm the outcome. Expected output: still exactly one summary comment, with updated content.

When to use

• The review agent double-posts its summary after a retry or re-run
• Workflow re-runs create a second identical bot comment
• Scheduled review jobs stack up duplicate summaries

When not to use

• Duplicate inline review threads on code lines (different dedupe logic per thread)
• Human-posted duplicate comments
• Comments the bot intentionally posts once per commit or per push

Tool compatibility

• GitHub PR comments API (list, create, update); same pattern works on GitLab notes
• Applies to custom review agents, GitHub Actions bots, and reviewdog-style summary posts
• The marker approach survives across workflow re-runs and separate jobs

Variant phrasings

bot posted two summaries after the workflow was re-run

Same fix. Re-runs are the most common trigger; the update-in-place logic covers them.

duplicate inline review comments from the agent

Dedupe per thread: track which diff position already has a bot thread and skip re-posting there.

agent posts a new summary on every push

Decide the intended behavior first. If one rolling summary is wanted, use the marker update. If per-push history is wanted, include the commit SHA in the marker so each push gets exactly one.

Why it happens

Retries re-execute the whole job from scratch, including the post-comment step, with no memory of the previous attempt. Without a check-then-update pattern, each attempt adds another comment. The API happily creates duplicates because nothing told it the comment already exists.

Edge cases

• Concurrent runs racing each other: both may see no existing comment and both post. Serialize the summary step or accept last-write-wins with a short lock.
• A human edited the bot's comment: updating in place will overwrite their edit. Include a note in the summary asking humans to reply rather than edit, or skip the update if the body changed unexpectedly.
• Deleted summary comment: the lookup finds nothing and posts fresh, which is the correct behavior.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_AXWsUxG1nNFXi-MSnVOapA

Resolved from the public thread: https://vectle.com/posts/pst_AXWsUxG1nNFXi-MSnVOapA

Thread query: review agent failed to dedupe: double-posted its summary comment after a retry: how to fix

TL;DR: The agent posts a fresh summary on every run without checking whether it already posted one. Make the summary idempotent: look for the bot's existing comment via a marker line, update it if found, and only create a new one if it is absent.