Webhook-idempotens: Når Stripe Affyrer Den Samme Provisions-Event Tre Gange

I 14 måneder loggede vi hver Stripe-webhook på thMenu: 312 ud af 100.000 events ankom med samme event_id to eller tre gange. Det er Stripes "at-least-once delivery"-løfte i konkrete tal — uden idempotens tre duplikater i provisionsbogen.

Hvorfor Samme Event Kommer Tre Gange

Hvis Stripe ikke modtager 2xx-svar inden ~10 sekunder, prøver igen. TCP-timeouts, lambda cold starts, midlertidige DNS-fejl, selv vellykket behandling efterfulgt af forbindelsesafbrydelse — alle udløser retries.

Tre hyppige scenarier: Cloudflare Workers cold start >10s, D1 batch-transaktion committed men forbindelse afbrudt, eller manuelt "resend"-klik i Stripe dashboard.

INSERT-Claim-mønstret

thMenus forsvar er tabellen stripe_webhook_events med event_id PRIMARY KEY. Første handling: INSERT. Unique constraint fejl 23505 = duplikat — 200 OK no-op.

Kritisk: claim skal komme før business logic for at undgå race conditions.

Race Condition: Events Uden for Rækkefølge

Reel hændelse: customer.subscription.updated ankom 800ms før checkout.session.completed. UPDATE påvirkede 0 rækker. Fix: rollback claim, returnér 503, Stripe prøver igen.

FAQ

Verificer signatur før eller efter claim? Før. Verify er billigt, DB-skrivning dyrt.

Hvor længe beholde idempotens-rækker? Stripe garanterer 30 dages retry; vi beholder 90 dage.

Prøver Stripe evigt? Nej, maksimalt 3 dage.

Var dette nyttigt? Del det.