Stripe husker forespørselen din når svaret forsvinner

Hva denne videoen dekker

• Idempotens handler om den tiltenkte effekten av å gjenta en operasjon. Stripe API v1 legger til en dokumentert lagret-svar-avspillingskontrakt.
• Et nytt forsøk på den samme logiske handlingen bruker den samme nøkkelen og parameterne. Oppretthold operasjonstasten på tvers av separate SDK-kall eller programomstarter; en genuint ny handling trenger sin egen nøkkel.
• Etter at endepunktutførelsen starter, lagrer Stripe API v1 den første forespørselens status og brødtekst, inkludert 500-feil, og returnerer det lagrede svaret ved nye forsøk.
• Endrede parametere med samme nøkkel produserer en uoverensstemmelse. Valideringsfeil og samtidige utførelseskonflikter lagrer ikke et idempotent resultat for det forsøket og kan prøves på nytt.
• Stripe beholder API v1-nøkler i minst 24 timer og kan deretter slette dem. Begrens uavklarte nettverksforsøk til de første 24 timene, stopp deretter og avstem før operasjonen gjentas.
• En hurtigbufret 500 kan fortsette å spille av etter at tilkoblingen er gjenopprettet. Den opprinnelige operasjonen kan ha bivirkninger; bruk det relevante objektet, Dashboard-forespørselen og webhooks for å fastslå utfallet.
• API v2 bruker annen avspillingssemantikk. En nøkkel etablerer ikke universell nøyaktig én gang levering for e-post, varelager og hver lokal databaseoperasjon.

Oversatt transkripsjon

Oversatt fra den originale engelske fortellingen. Tilgjengelig lyd og undertekster kontrolleres av YouTube.

Kansellerte en tidsavbrudd betalingen din?

0:00 Du tror en tidsavbrudd betyr at betalingen din mislyktes. Serveren kan fullføre mens svaret forsvinner, og lar utsjekkingen din trygt vise absolutt ingenting. Hvorfor kan et nytt forsøk belaste igjen? Hvordan husker Stripe et forsøk? Når bør du slutte å prøve på nytt? Og husk en ekkel detalj. En husket feil kan overleve nettverksproblemet.

0:17 Vi kommer tilbake til det. Dette er The Daily Diff, under panseret.

Hva identifiserer en idempotensnøkkel?

0:21 Idempotens betyr at gjentakelse av en operasjon har samme tiltenkte effekt som å gjøre det en gang. En idempotensnøkkel merker en logisk handling. Stripes API versjon én gjenkjenner den etiketten ved nye forsøk og spiller av et lagret svar. Se for deg å kjøpe en kaffe. Stripe fullfører betalingsforespørselen din, og svaret går tapt når det kommer hjem. Kunden ser en snurrer. Banken deres kan ha en mer spennende tolkning. En ubeskyttet opprettelsesforespørsel kan gjenta sideeffekten.

Hvordan gjør den samme nøkkelen et nytt forsøk trygt?

0:45 Fest en unik nøkkel før det første forsøket og behold den for nye forsøk. Hvis applikasjonen din starter på nytt, bevar den nøkkelen med operasjonen i registrene dine. For Stripes versjon én API, når endepunktutførelsen starter, lagres den første forespørselens status og brødtekst. Send den samme nøkkelen og parameterne igjen, og Stripe returnerer det lagrede svaret. Kaffen blir stående mens kvitteringen reiser igjen.

Hva lagrer Stripe egentlig?

1:07 Her er Stripes faktiske ordlyd. Nye forsøk med samme nøkkel returnerer det lagrede svaret, inkludert fem hundre feil. Dokumentasjonen gjør mer arbeid enn din optimistisk navngitte hjelper for nye forsøk. Kunden trykker igjen. Appen din bestemmer om det gjenopptar det ventende kjøpet eller starter et annet ett. En genuint ny kaffe får en ny nøkkel. En fersk nøkkel for hvert nettverksforsøk opphever beskyttelsen.

1:27 Ulike parametere med samme nøkkel utløser en uoverensstemmelse.

Hva skjer når forespørselen endres?

1:30 Hvis parametere mislykkes i valideringen, eller en annen forespørsel med den nøkkelen fortsatt utføres, lagrer Stripe ikke et idempotent resultat for det forsøket. Disse forespørslene kan prøves på nytt. En racing-forespørsel får en konflikt. Dette er versjon én-regler. Versjon to oppfører seg annerledes. En header kan ikke love nøyaktig én gang levering på tvers av systemet ditt. E-post, varelager og databasen din trenger hver for seg feilhåndtering.

1:52 Nøkkelen beskytter operasjonen innenfor sitt dokumenterte omfang. Stripe beholder versjon én-nøkler i minst tjuefire timer og kan beskjære

Hvor lenge er det husket resultatet trygt å prøve på nytt?

1:59 dem deretter. En beskjært nøkkel kan utføre en ny forespørsel. Hold uoppklarte forsøk innenfor den første dagen. Utover det, stopp og avstem det opprinnelige utfallet. Bruk eksponentiell tilbakestilling og jitter for å gi serveren pusterom. Ellers danner nye forsøk en kø utenfor en brennende kaffebar. Stripes biblioteker håndterer nye forsøk, men sjekk bibliotekets standardinnstillinger. Den klebrige feilen er haken.

Hvorfor kan en husket feil fortsette å komme tilbake?

2:20 Et hurtigbufret fem hundre svar fortsetter å spille av etter at tilkoblingen er gjenopprettet. Den opprinnelige operasjonen kan ha produsert sideeffekter. Løs utfallet ved hjelp av objekter, Dashboard og webhooks. En ny nøkkel kan gjenta handlingen. Hvis du heller vil lese dette enn å høre meg si det, lander diffen i innboksen din hver morgen, gratis på the daily diff dot dev, lenke nedenfor.

Ville jeg sendt en prøv igjen-knapp med denne kontrakten?

2:39 Dommen, under panseret. SHIP IT. Jeg ville sendt stabile nøkler med begrensede nye forsøk og avstemming, slik at kundene får kaffe uten å finansiere din utdanning i distribuerte systemer. Og det er diffen for i dag. Jeg er Niko fra Axrisi. Flett ansvarlig.

Kilder

1. Idempotent requestsStripe Docs
2. Designing robust and predictable APIs with idempotencyStripe Engineering — Brandur Leach
3. Advanced error handlingStripe Docs
4. HTTP Semantics — RFC 9110 §9.2.2 Idempotent MethodsIETF / RFC Editor