review agent opened a duplicate review thread on an already-resolved conversation

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: Do not close and reopen to refresh a stale PR - update the existing branch in place by rebasing or merging main and pushing. Closing discards the review thread and the approved CI run, and the new PR starts from zero trust. If the old branch is truly unrecoverable, link the closed PR prominently in the new description and carry the review conclusions over.

agent closed a stale upgrade PR and opened a fresh one, losing the review thread and the approved CI run

1. Check whether the old PR's branch still exists and whether the PR can be reopened. Expected: you know if in-place recovery is possible or the branch is gone.
2. If the branch exists, reopen the old PR (or push the refreshed branch to it) and close the duplicate. Expected: a single PR carrying the full review and CI history.
3. If the branch is gone: in the new PR description, link the closed PR and paste the key review conclusions plus the approved CI run link. Expected: reviewers see the carried-over context without digging through closed PRs.
4. Re-run CI on the surviving PR and re-request review, noting explicitly what changed versus the closed one. Expected: fresh approvals on the actual code being merged - nothing carried over silently.
5. Teach the agent: stale PRs get refreshed in place; close-and-reopen is only for a corrupt branch, and then a link-back is mandatory. Expected: future stale PRs keep their threads.

Use this when

• An agent closed an upgrade PR and opened a duplicate
• Review comments or an approved CI run were lost in the shuffle
• You need to recover continuity between the old and new PR
• A bot or agent keeps "refreshing" PRs by closing them

Not for this skill when

• The PR was closed because the upgrade itself was abandoned - that is fine
• The new PR properly supersedes the old one with a link-back already in place
• Your workflow already refreshes PRs in place with rebases

Variant phrasings

• Agent reopened upgrade PR, lost review comments
• Closed stale PR and opened new one, lost approvals
• Duplicate upgrade PR
• Refresh by close-and-reopen lost CI history

Why it happens

The agent treats "stale" as "broken" and its refresh primitive is close-plus-open, because it does not model review threads and CI approvals as state that lives on the PR object. To the agent the diff is identical, so the new PR looks equivalent - but the human trust (reviews, green runs) was attached to the old PR number, not to the diff.

Edge cases

• Some repos auto-delete branches on close - restore the branch from the reflog or a local copy first
• If main moved on, the reopened PR needs a rebase anyway - watch for the approval-invalidation trap when you do
• Bots that auto-close stale PRs need an exemption label for agent upgrade PRs under active review

Provenance

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

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

Thread query: agent closed a stale upgrade PR and opened a fresh one, losing the review thread and the approved CI run

TL;DR:

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.