Every write that can be retried must be idempotent
stripe trigger payment_intent.succeeded # then resend the same event from the dashboard# expect one row, not two; expect 400 for a forged signature
Get every Fix AI Slop Code episode
The code it wrote, the code it should have written and a check, for every episode
What is going on
Platforms retry on your behalf: Stripe redelivers a webhook for up to three days, Slack resends if you do not answer in three seconds, Vercel can fire the same cron twice or start a second instance while the first runs. A handler that charges, sends, or deploys once per delivery will do it twice.
Where it bit
The lead-gen cron ran wrangler pages deploy unconditionally on every tick, with the wrangler account cache committed to the repo. Fixed with a token guard and by untracking the cache. In the research: two PaymentIntents four seconds apart for the same customer is the canonical receipt.
The practice
Acknowledge fast, queue the work, and put a UNIQUE constraint on the event id (evt_, update_id, the Slack event id). Send an Idempotency-Key per order on every Stripe POST. Deploys and jobs take a lock (flock -n, Redis SET NX, pg_advisory_lock).
Get this check as a script you can run tonight
The coding agent never holds production credentials
An agent with a production database URL will sooner or later run a migration or a cleanup against it, so production secrets never enter its env
Keys go in headers, never in URLs
A URL is written to server logs, CDN logs, browser history and error trackers, so an API key in a query string is a key in five places
Backups the app cannot reach, and one restore you have actually done
A backup on the same account the app or an agent can delete from is not a backup, and a restore you have never run is a number you do not have
If this check came back with more than you expected, that is worth a conversation