Fix race condition in checkout webhook

Opened from Mobile App Redesign · Sprint 24

To Do5

Onboarding empty state illustrations

Push notification preferences screen

In Progress4

Highest

Fix race condition in checkout webhook

PAY-2143

3d overdue

Apple Pay integration for iOS checkout

Migrate user sessions to Redis store

In Review3

Checkout summary redesign

Fix race condition in checkout webhook

When two checkout webhooks arrive within ~50ms of each other (common with Stripe retry + duplicate delivery), the order record can be updated concurrently and the second handler overwrites the payment_status set by the first.

Repro: fire checkout.session.completed twice in quick succession against the staging endpoint — the second call resets status to pending even though payment succeeded.

Fix should use an idempotency key on session_id with a row-level lock before mutating order state. Add a regression test in webhooks.test.ts.

Subtasks 2 of 4 done

Add idempotency key column to order_events

Wrap handler in SELECT … FOR UPDATE

Regression test for duplicate delivery

Backfill idempotency key on last 30 days

Attachments

webhook-duplicate-trace.log

412 KB · Devon · Jun 14

duplicate-delivery-sequence.png

88 KB · Devon · Jun 14

Drop files or browse

Comments · 7

Activity · 14

Devon Park2 hours ago

Reproduced consistently with the staging duplicate-delivery script. Locking order_events by session_id eliminates the overwrite — pushed a draft PR.

Maya Chen5 hours ago

Good catch. Let's also guard the backfill so we don't re-emit receipts for already-settled orders. Flag if the retry window exceeds 24h.

Theo Wellsyesterday

Stripe documents up to 3-day retry windows for some events — worth handling the long tail explicitly.

Activity history

Devon Park moved this to In Progress · Jun 14, 09:12

Maya Chen assigned to Devon Park · Jun 13, 17:40

Priority raised to Highest by Maya Chen · Jun 13, 17:38

Theo Wells estimated 3 points · Jun 12, 14:05

Maya Chen created this task · Jun 11, 10:22