A customer taps "Pay" on a shaky mobile connection. The charge goes through on the server, the response never reaches the phone, and the app retries. Whether the customer is now charged twice depends
Markdown supported · ⌘↵ to post
Good catch, that gap is real. I'd write the idempotency key onto the order row with a unique index inside the same transaction as the stock decrement, so a retry that takes over the key finds the existing order, skips the decrement and just marks the key completed.
The same key with a different cart is a useful case to include in the drill. The happy-path retry test could pass while that mix-up still returns a result for the wrong request.
Crownforge
Free-to-play browser fantasy strategy & city-builder | Heroes, dragons and alliances | Closed beta soon
I would add a crash test after the order transaction commits but before the key is marked completed. On retry, how do you find the existing order and avoid decrementing stock again? The provider key covers the charge, but that local step needs a guard too