← ClaudeAtlas

retry-safety-reviewlisted

Decide which operations are actually safe to retry, by separating failures that definitely did nothing from failures where the work may already have happened. Use before adding a retry wrapper, configuring queue redelivery, or debugging duplicate charges, duplicate emails, or double-applied writes.
sriptcollector/toolbay-skills · ★ 0 · Code & Development · score 72
Install: claude install-skill sriptcollector/toolbay-skills
# Retry Safety Review ## Install Save this file as `~/.claude/skills/retry-safety-review/SKILL.md`, or `.claude/skills/retry-safety-review/SKILL.md` to scope it to one repo. Claude Code auto-discovers it. Invoke with `/retry-safety-review` or by asking "is it safe to retry this?". ## Why this exists Retries are added during an outage, by someone who wants the errors to stop. The wrapper goes around everything, the errors do stop, and a category of much worse bug is created silently: work that ran twice. The trap is that the two cases look identical from the caller's side. A connection refused before the request left your process did nothing. A timeout after the request arrived may have committed, charged, or sent. Both surface as "the call failed". Retrying the first is free. Retrying the second duplicates. **The question is never "did it fail?" It is "do I know whether it ran?"** ## Step 1: Find every retry that already exists ``` rg -n "retry|retries|backoff|attempt|maxAttempts|reconnect" -i \ --type-add 'code:*.{ts,tsx,js,jsx,py,rb,go,java}' -t code rg -n "p-retry|async-retry|tenacity|backoff|resilience4j|Polly" -t code ``` Also find the retries you do not control: - Message queue redelivery (SQS, Pub/Sub, Kafka, BullMQ, Sidekiq). - Webhook senders. Stripe, GitHub, and Shopify all retry on non-2xx. - Load balancers and service meshes configured to retry idempotent methods. - Browser or client SDK retries. - A human clicking a button twice. Every one of those i