May 10, 2026
Same button, bigger chaos
Idempotency Is Easy Until the Second Request Is Different
That “simple retry” trick turns messy fast — and the comments are absolutely fighting over it
TLDR: The article argues that preventing accidental duplicate actions only looks easy until the repeated request changes or the system crashes halfway through. Commenters split hard: some said the author was mixing different problems together, while others backed strict rejection as the only sane way to catch dangerous bugs early.
A seemingly nerdy post about how apps handle accidental repeat requests somehow turned into a full-on comment section cage match. The article’s big point is simple: stopping duplicate actions is easy in the demo, but real life gets chaotic the second the “same” request comes back a little different. Maybe the app crashed halfway through, maybe the payment went through but the system forgot to write it down, or maybe someone reused the same retry code for 10 euros and then 100 euros. That’s where the author says the real nightmare begins: should the system repeat the old result, reject it, or treat it as brand-new?
And the community? Oh, they had opinions. One camp basically yelled, “Hold on — half of this isn’t even the same problem!” with stavros arguing that crashes and half-finished work are really about systems failing safely, not about duplicate requests. Another group went full practical mode: chaz6 dropped the classic engineer answer — keep a fingerprint of the original request and hard reject anything that tries to sneak in with the same key but different details. Meanwhile, shiandow pushed back on the idea that a repeated request must get the exact same response, saying the goal is the same final result, not identical wording.
The funniest energy came from battle-scarred veterans who sounded like they’d seen this movie before. One commenter praised the article like a horror story with receipts, recalling multiple engineers confidently building “generic” duplicate-prevention tools that blew up in production. The vibe was part therapy session, part pedantic duel, part “this is why your bank app makes everyone nervous.”
Key Points
- •The article argues that replaying a stored response by idempotency key only handles the simplest retry case and does not cover the full idempotency problem.
- •It identifies several difficult scenarios, including concurrent retries, partial local success, unknown downstream state, duplicate operations without a key, and retries after expiry or infrastructure changes.
- •The article highlights reuse of the same idempotency key with different request content as a key design decision that requires an explicit server policy.
- •For side-effecting APIs, the article says a repeated scoped key with a different canonical command should be treated as a hard error.
- •It defines idempotency in terms of intended effect rather than response sameness and notes that uniqueness constraints alone do not guarantee correct retry behavior or side-effect control.