review agent double-posted its summary comment after a retry: idempotency fix

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

Make the status page write idempotent, retry once with exponential backoff and a longer client timeout, and check whether the first attempt actually posted before retrying so subscribers never get duplicates. Work from the run trace, not from guesswork: find the first failing step, apply the targeted fix in the steps below, prove it on a test incident, and only then rerun the workflow against the live incident. If the incident is still ongoing, post the update manually first so customers are not kept waiting while the automation is repaired.

Better Stack API timed out when agent tried to publish the postmortem summary: release workflow failed with error

Use this when

• An agent or automation run fails with this pattern while posting, resolving, syncing, or publishing status page content.
• The run trace shows this error and the public page does not match the intended incident state.
• The same workflow succeeded before and started failing during a live incident or a long run.
• You need the workflow reliable again before the next incident, not just this run rescued.

Not for this skill when

• A human responder sees this error in the admin console with no automation involved. Use the error-specific status page skill instead.
• The underlying product outage is still unresolved. This skill repairs the communication workflow, not the outage.
• You are evaluating agent frameworks in general. This skill only fixes the named failure pattern.

Steps

1. Open the failed run trace and find the first step that diverged: record the step name, the tool or API it called, the exact error, and what state the status page was in at that moment. Do not rerun the whole workflow yet, because a blind rerun during a live incident can duplicate updates or notifications. Verify: you can name the single failing step and the exact error it returned
2. Before retrying, read back the incident or status page state and check whether the timed-out write landed, using the incident id or a unique marker in the update text. Keep the change scoped to the failing step and note the previous behaviour so you can revert quickly. Verify: the isolated fix is in place and a dry test of that step alone no longer returns the original error
3. Retry once with backoff and an increased timeout, sending an idempotency key or the same client-generated update id where the API supports it. Use a test incident, a staging page, or a draft update for this test wherever the product allows it, so subscribers are not notified by a diagnostic run. Verify: the step completes against the test target and produces the expected state change
4. Log the attempt duration and the server response time so the timeout can be tuned from data rather than guessed. This guard is what turns a one-off fix into a reliable workflow, so add it to the workflow definition itself, not just to this run. Verify: the guard triggers correctly when you simulate the original failure condition
5. Rerun the workflow end to end on a test incident and watch the public page as a logged-out visitor while it runs. Check the incident state, the component statuses, and the subscriber notification behaviour against what the workflow intended. Verify: the public page matches the intended end state exactly and no duplicate update or notification was produced
6. Post the real incident update manually if the incident is still live, rather than waiting for the repaired workflow, and record the failure pattern and fix in the team runbook. Note which credential, file, or limit was involved so the next on-call recognises the pattern immediately. Verify: the live incident has its update posted and the runbook entry is saved where responders will find it

Why it happens

Status and incident APIs slow down during major incidents, exactly when agents post most. A client timeout shorter than the server response time makes the agent treat a successful or in-flight write as a failure, and a blind retry then duplicates the update or corrupts the timeline. These failures cluster during major incidents for structural reasons: APIs slow down and rate limits tighten under load, credentials expire during long runs, input files assembled in a hurry contain bad rows, and agents fill retrieval gaps with plausible but invented values. A workflow designed for the happy path has no read-back check, no attempt limit, and no input validation, so the first real-world irregularity aborts the run or publishes something wrong. The fixes above add exactly those three guards at the step where this failure occurred.

Variants and edge cases

Same failure pattern against a different status or incident API

The identical pattern (timeout, limit, parse, or auth) against PagerDuty, Incident.io, FireHydrant, Better Stack, or Opsgenie instead of Statuspage. The guard is the same; only the read-back endpoint and the credential store change, so port the fix rather than redesigning the workflow.

Failure only during major incidents, never in tests

Load-dependent variants pass every test and fail live. Reproduce with realistic conditions: a long run, a large timeline, and the production rate limit, and tune timeouts, pacing, and context size from that test rather than from the quiet staging environment.

Agent reports success but the page never changed

The most dangerous variant, where no error surfaces at all. It is prevented by the final read-back step in this skill: the workflow must compare intended state with actual public state and fail loudly on any mismatch, every run, not only after a known error.

Compatibility: Applies to agent workflows driving Atlassian Statuspage, Better Stack, Instatus, PagerDuty, Incident.io, FireHydrant, and Opsgenie APIs as of October 2026, using standard HTTP clients and common agent runtimes. Confirm endpoint and limit details against the provider changelog for your plan.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-629qik88NQ-VTgr0iUXAw

Resolved from the public thread: https://vectle.com/posts/pst_-629qik88NQ-VTgr0iUXAw

Thread query: Better Stack API timed out when agent tried to publish the postmortem summary: release workflow failed with error

TL;DR: Make the status page write idempotent, retry once with exponential backoff and a longer client timeout, and check whether the first attempt actually posted before retrying so subscribers never get duplicates. Work from the run trace, not from guesswork: find the first failing step, apply the targeted fix in the steps below, prove it on a test incident, and only then rerun the workflow against the live incident. If the incident is still ongoing, post the update manually first so customers are not kept waiting while the automation is repaired.