Stripe husker din anmodning, når svaret forsvinder

Hvad denne video dækker

• Idempotens handler om den tilsigtede effekt af at gentage en operation. Stripe API v1 tilføjer en dokumenteret kontrakt for genafspilning af gemte svar.
• Et genforsøg af den samme logiske handling bruger den samme nøgle og parametre. Bevar operationsnøglen på tværs af separate SDK-kald eller applikationsgenstarter; en ægte ny handling kræver sin egen nøgle.
• Efter at endpoint-udførelsen er påbegyndt, gemmer Stripe API v1 den første anmodnings status og brødtekst, inklusive 500-fejl, og returnerer det gemte svar ved genforsøg.
• Ændrede parametre med den samme nøgle producerer et mismatch. Valideringsfejl og samtidige udførelseskonflikter gemmer intet idempotent resultat for det forsøg og kan genforsøges.
• Stripe beholder API v1-nøgler i mindst 24 timer og kan derefter slette dem. Begræns uafklarede netværksgenforsøg til de første 24 timer, stop derefter og afstem, før operationen gentages.
• En cachelagret 500-fejl kan fortsætte med at genafspilles, efter at forbindelsen er genoprettet. Den oprindelige operation kan have bivirkninger; brug det relevante objekt, Dashboard-anmodning og webhooks til at fastslå dens resultat.
• API v2 bruger forskellige genafspilningssemantik. En nøgle etablerer ikke universel nøjagtigt én gang levering for e-mail, lager og enhver lokal databaseoperation.

Oversat udskrift

Oversat fra den originale engelske fortælling. Tilgængelig lyd og undertekster styres af YouTube.

Annullerede en timeout din betaling?

0:00 Du tror, at en timeout betyder, at din betaling mislykkedes. Serveren kan afslutte, mens svaret forsvinder, hvilket efterlader din checkout trygt og roligt uden noget som helst. Hvorfor kan et genforsøg opkræve igen? Hvordan husker Stripe et forsøg? Hvornår skal du stoppe med at genforsøge? Og husk en grim detalje. En husket fejl kan overleve netværksproblemet.

0:17 Det vender vi tilbage til. Dette er The Daily Diff, bag kulisserne.

Hvad identificerer en idempotensnøgle?

0:21 Idempotens betyder, at gentagelse af en operation har den samme tilsigtede effekt som at gøre det én gang. En idempotensnøgle mærker én logisk handling. Stripes API version et genkender det mærke ved genforsøg og afspiller et gemt svar. Forestil dig at købe en kop kaffe. Stripe fuldfører din betalingsanmodning, og svaret går tabt på vej tilbage hjem. Kunden ser en spinner. Deres bank har måske en mere spændende fortolkning. En ubeskyttet oprettelsesanmodning kan gentage bivirkningen.

Hvordan gør den samme nøgle et genforsøg sikkert?

0:45 Vedhæft en unik nøgle før første forsøg og behold den til genforsøg. Hvis din applikation genstarter, bevar denne nøgle med operationen i dine optegnelser. For Stripes version et API, når endpoint-udførelsen begynder, gemmes den første anmodnings status og brødtekst. Send den samme nøgle og parametre igen, og Stripe returnerer det gemte svar. Kaffen forbliver, mens kvitteringen rejser igen.

Hvad gemmer Stripe præcist?

1:07 Her er Stripes faktiske ordlyd. Genforsøg med den samme nøgle returnerer det gemte svar, inklusive fem hundrede fejl. Dokumentationen gør mere arbejde end din optimistisk navngivne genforsøgshjælper. Kunden trykker igen. Din app afgør, om det genoptager det afventende køb eller starter et nyt et. En ægte ny kaffe får en ny nøgle. En frisk nøgle for hvert netværksgenforsøg annullerer beskyttelsen.

1:27 Forskellige parametre med den samme nøgle udløser et mismatch.

Hvad sker der, når anmodningen ændres?

1:30 Hvis parametre fejler validering, eller en anden anmodning med den nøgle stadig udføres, gemmer Stripe intet idempotent resultat for det forsøg. Disse anmodninger kan genforsøges. En konkurrerende anmodning får en konflikt. Disse er version et regler. Version to opfører sig anderledes. En header kan ikke love nøjagtigt én gang levering på tværs af dit system. E-mail, lager og din database har hver brug for fejlhåndtering.

1:52 Nøglen beskytter operationen inden for dens dokumenterede omfang. Stripe beholder version et nøgler i mindst fireogtyve timer og kan fjerne

Hvor længe er det huskede resultat sikkert at genforsøge?

1:59 dem derefter. En fjernet nøgle kan udføre en ny anmodning. Bevar uafklarede genforsøg inden for den første dag. Ud over det, stop og afstem det oprindelige resultat. Brug eksponentiel backoff og jitter for at give serveren pusterum. Ellers danner genforsøg en kø uden for en brændende kaffebar. Stripes biblioteker håndterer genforsøg, men tjek dit biblioteks standardindstillinger. Den vedvarende fejl er faldgruben.

Hvorfor kan en husket fejl blive ved med at komme tilbage?

2:20 Et cachelagret fem hundrede svar fortsætter med at afspille, efter at forbindelsen er genoprettet. Den oprindelige operation kan have produceret bivirkninger. Løs dens resultat ved hjælp af objekter, Dashboard og webhooks. En ny nøgle kan gentage handlingen. Hvis du hellere vil læse dette end høre mig sige det, lander diffen i din indbakke hver morgen, gratis på the daily diff dot dev, link nedenfor.

Ville jeg sende en genforsøgsknap med denne kontrakt?

2:39 Dom, bag kulisserne. Send det. Jeg ville sende stabile nøgler med begrænsede genforsøg og afstemning, så kunderne får kaffe uden at finansiere din uddannelse i distribuerede systemer. Og det er forskellen for i dag. Jeg er Niko fra Axrisi. Flet ansvarligt.

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