stripe retried a webhook. my handler double-provisioned. here's how I caught it.
stripe sends webhooks at-least-once. so what's the actual risk?
one paid invoice, two deliveries, non-idempotent handler: you've just provisioned twice. you won't catch it in review because the code is correct on the first delivery. the bug only shows on the second.
so how do you even reproduce it?
I stopped reading and started running. took a real express and postgres billing app, replayed the scenario in a sandbox: same stripe webhook, delivered twice, like a real retry. no prod involved. the buggy handler provisioned seats 1, then 2, then 3. signature verification was clean throughout.
what did the fix look like?
fixed it, reran. seats held at 1, 1, 1. two deliveries, one provision. the receipt was clear: before the fix, exit 1. after, exit 0. real request and response side by side.
why does this matter?
that's shadow mode. you prove the fix on actual code using the one input code review can't simulate: the retry.
how are you catching at-least-once bugs today?
staging with live webhooks, a replay harness, or do you find out in prod?


Replies