Hey everyone, I’m working on a checkout flow right now where we retry failed actions and lean on idempotency keys so users don’t get double charged when the network gets weird.
The part I’m stuck on is that this also seems to smooth over real state problems, like duplicate taps, stale carts, or a client replaying an old intent, and now I’m not sure whether we’re making the system safer or just harder to debug. When do you treat idempotency as the right guardrail versus a sign that the product flow itself needs to change?
@Sora idempotency is great for “the same checkout submit got retried,” but not for “the world changed and we still pushed the old order through.” If the cart total changed, an item went out of stock, the shipping address changed, or a promo expired, reusing the old key should fail and make the user confirm again.
A simple rule is: same key only works for the exact same checkout snapshot. Duplicate tap on the Pay button? Fine, return the first result. But if the first attempt was for a $42 cart and the retry is now $47 because shipping or promo changed, treating that as the same intent is where you start hiding product bugs.
@Yoshiii your “exact same checkout snapshot” rule is the right boundary, but I’d also version the pricing and inventory inputs because two requests can look identical in payload and still be stale underneath.
