review agent failed to dedupe: double-posted its summary comment afte

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.

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

Review the three-dot diff between the PR head and the base branch, never the merge commit. A merge commit's tree folds in base-branch changes, so the agent re-reviews code it already saw and posts duplicate findings. Pin the review to the PR head SHA and dedupe every finding against existing review comments before posting.

The problem

review agent failed to review the PR diff: reviewed the merge commit instead: how to fix

When to use

• Inline comments appear on files the PR's Files changed tab does not list
• The same finding gets posted twice across two runs of the review agent
• Review counts include hunks from the base branch
• The agent was pointed at refs/pull/N/merge or at a merge-commit SHA

When not to use

• Findings are duplicates because the agent re-ran on the same diff (a rerun-dedupe issue, not a merge-commit issue)
• The agent failed to parse the diff at all (a parser problem, not a ref problem)
• GitHub shows "outdated" on old comments after a push (normal behavior, not a merge-commit bug)

Steps

1. Confirm which ref the agent actually reviewed

Check the agent's config or logs for the ref it fetched. Look for refs/pull/123/merge, a /merge suffix, or a merge-commit SHA.

gh pr view 123 --json headRefOid,baseRefName --jq '{head: .headRefOid, base: .baseRefName}'

Expected output: the real head SHA and base branch name to compare against the agent's log.

2. Reproduce the bad diff locally

git fetch origin pull/123/head:pr-123 pull/123/merge:pr-123-merge
git diff --stat pr-123-merge^1 pr-123-merge
git diff --stat origin/main...pr-123

Expected output: the merge-ref diff shows extra base-branch files; the three-dot diff shows only the PR's files. That gap is the duplicate source.

3. Repoint the agent at the head ref

Change the agent's fetch to the head ref (pull/123/head) or the pinned head SHA from step 1. Never hand it the /merge ref.

Expected output: the agent's file list matches the Files changed tab exactly.

4. Dedupe findings against existing review comments before posting

gh api repos/OWNER/REPO/pulls/123/comments --paginate -q '.[].path' | sort | uniq -c | sort -rn | head -20

Skip findings whose path and lines overlap an existing comment, or whose normalized text matches a posted one. Expected output: zero re-posts; only net-new comments go out.

5. Record the reviewed head SHA on the review

Put the reviewed head SHA in the summary footer or run metadata. Expected output: later runs see which SHA was already reviewed and skip cleanly instead of re-posting.

Tool compatibility

• GitHub REST API and git CLI: the pull/N/head and pull/N/merge ref convention is stable across github.com and GHES.
• gh CLI 2.x: pr view --json headRefOid,baseRefName works on all recent releases.
• Agents that diff two SHAs: pass base and head SHAs explicitly, never a ref name, so a moving ref cannot swap in the merge commit.

Variant phrasings

review bot commented on code outside the PR

Same root cause in most cases. Verify the agent's diff source first; if the ref is correct, check whether the file list came from a cached full-tree scan instead of the diff.

duplicate findings across review runs

When the ref is already correct, duplicates usually mean no dedupe pass ran before posting. Add the step-4 dedupe; it fixes both the merge-commit case and plain re-run duplication.

agent reviewed base branch files in the PR

Confirm with the step-2 reproduction. If the three-dot diff is clean but the agent still saw base files, the agent is scanning the working tree instead of the diff - a different bug in file-enumeration scope.

Why it happens

GitHub synthesizes a test-merge commit per PR so CI runs against the merged result. Its tree contains the full base branch, so diffing against its first parent surfaces base-branch changes as new. Agents fetching refs/pull/N/merge for convenience inherit that polluted diff.

Edge cases

• Draft PRs: the /merge ref may not exist yet or may be stale; the head ref is the only reliable source.
• Merge-queue PRs: the queue rewrites history, so re-resolve the head SHA right before the review pass.
• Squash-merge setups: the merge commit contains the whole PR; agents must still review the pre-squash diff.
• Fork PRs: pull/N/head lives in the fork; make sure the fetch refspec includes it or the fetch silently goes stale.

Provenance

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

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

Thread query: review agent failed to review the PR diff: reviewed the merge commit instead: how to fix

TL;DR: Review the three-dot diff between the PR head and the base branch, never the merge commit. A merge commit's tree folds in base-branch changes, so the agent re-reviews code it already saw and posts duplicate findings. Pin the review to the PR head SHA and dedupe every finding against existing review comments before posting.