Stripe onthoudt je verzoek wanneer het antwoord verdwijnt

Wat deze video behandelt

• Idempotentie betreft het beoogde effect van het herhalen van een bewerking. Stripe API v1 voegt een gedocumenteerd contract voor het herhalen van opgeslagen antwoorden toe.
• Een nieuwe poging van dezelfde logische actie gebruikt dezelfde sleutel en parameters. Bewaar de bewerkingssleutel over afzonderlijke SDK-aanroepen of applicatiestarts heen; een echt nieuwe actie heeft zijn eigen sleutel nodig.
• Nadat de uitvoering van het eindpunt is begonnen, slaat Stripe API v1 de status en inhoud van het eerste verzoek op, inclusief 500-fouten, en retourneert dat opgeslagen antwoord bij nieuwe pogingen.
• Gewijzigde parameters met dezelfde sleutel produceren een mismatch. Validatiefouten en gelijktijdige uitvoeringsconflicten slaan geen idempotent resultaat op voor die poging en kunnen opnieuw worden geprobeerd.
• Stripe bewaart API v1-sleutels minstens 24 uur en kan ze daarna opschonen. Beperk onopgeloste netwerkherhalingen tot de eerste 24 uur, stop dan en stem af voordat de bewerking wordt herhaald.
• Een in de cache opgeslagen 500 kan blijven afspelen nadat de connectiviteit is hersteld. De oorspronkelijke bewerking kan neveneffecten hebben; gebruik het relevante object, Dashboard-verzoek en webhooks om het resultaat vast te stellen.
• API v2 gebruikt andere replay-semantiek. Een sleutel zorgt niet voor universele precies-één-keer-levering voor e-mail, voorraad en elke lokale databasebewerking.

Vertaald transcript

Vertaald vanuit de originele Engelse gesproken tekst. Beschikbare audio en ondertiteling worden beheerd door YouTube.

Heeft een time-out uw betaling geannuleerd?

0:00 Je denkt dat een time-out betekent dat je betaling is mislukt. De server kan klaar zijn terwijl het antwoord verdwijnt, waardoor je afrekening vol vertrouwen absoluut niets weergeeft. Waarom kan een nieuwe poging opnieuw in rekening brengen? Hoe onthoudt Stripe een poging? Wanneer moet je stoppen met opnieuw proberen? En houd één vervelend detail in gedachten. Een onthouden fout kan het netwerkprobleem overleven.

0:17 Daar komen we op terug. Dit is The Daily Diff, under the hood.

Wat identificeert een idempotentiesleutel?

0:21 Idempotentie betekent dat het herhalen van een bewerking hetzelfde beoogde effect heeft als het één keer doen. Een idempotentiesleutel labelt één logische actie. Stripe's API-versie één herkent dat label bij nieuwe pogingen en speelt een opgeslagen antwoord opnieuw af. Stel je voor dat je koffie koopt. Stripe voltooit je betalingsverzoek, en het antwoord raakt zoek bij terugkomst naar huis. De klant ziet een spinner. Hun bank heeft misschien een spannendere interpretatie. Een onbeschermd aanmaakverzoek kan het neveneffect herhalen.

Hoe maakt dezelfde sleutel een nieuwe poging veilig?

0:45 Voeg een unieke sleutel toe vóór de eerste poging en bewaar deze voor nieuwe pogingen. Als je applicatie opnieuw opstart, bewaar die sleutel dan met de bewerking in je gegevens. Voor Stripe's versie één API, zodra de uitvoering van het eindpunt begint, worden de status en inhoud van het eerste verzoek opgeslagen. Stuur dezelfde sleutel en parameters opnieuw, en Stripe retourneert het opgeslagen antwoord. De koffie blijft staan terwijl de bon opnieuw reist.

Wat slaat Stripe precies op?

1:07 Hier is de exacte bewoording van Stripe. Nieuwe pogingen met dezelfde sleutel retourneren het opgeslagen antwoord, inclusief vijfhonderd fouten. De documentatie doet meer werk dan je optimistisch genoemde retry-helper. De klant tikt opnieuw. Je app beslist of dat de lopende aankoop hervat of een andere begint. Een echt nieuwe koffie krijgt een nieuwe sleutel. Een nieuwe sleutel voor elke netwerkherhaling ondermijnt de bescherming.

1:27 Verschillende parameters met dezelfde sleutel leiden tot een mismatch.

Wat gebeurt er als het verzoek verandert?

1:30 Als parameters niet gevalideerd worden, of een ander verzoek met die sleutel nog steeds wordt uitgevoerd, slaat Stripe geen idempotent resultaat op voor die poging. Die verzoeken kunnen opnieuw worden geprobeerd. Een race-verzoek krijgt een conflict. Dit zijn versie één regels. Versie twee gedraagt zich anders. Een header kan geen precies één keer levering garanderen in je systeem. E-mail, inventaris en je database hebben elk foutafhandeling nodig.

1:52 De sleutel beschermt de bewerking binnen de gedocumenteerde scope. Stripe bewaart versie één sleutels minstens vierentwintig uur en kan ze daarna

Hoe lang is het onthouden resultaat veilig om opnieuw te proberen?

1:59 opschonen. Een opgeschoonde sleutel kan een nieuw verzoek uitvoeren. Houd onopgeloste herhalingen binnen de eerste dag. Daarna, stop en stem het oorspronkelijke resultaat af. Gebruik exponentiële backoff en jitter om de server ademruimte te geven. Anders vormen herhalingen een wachtrij buiten een brandende koffiebar. Stripe's bibliotheken behandelen herhalingen, maar controleer de standaardinstellingen van je bibliotheek. Die hardnekkige fout is de valkuil.

Waarom kan een onthouden fout blijven terugkomen?

2:20 Een in de cache opgeslagen vijfhonderd antwoord blijft afspelen nadat de connectiviteit is hersteld. De oorspronkelijke bewerking kan neveneffecten hebben veroorzaakt. Los het resultaat op met behulp van objecten, het Dashboard en webhooks. Een nieuwe sleutel kan de actie herhalen. Als je dit liever leest dan mij het hoort zeggen, de diff landt elke ochtend gratis in je inbox op the daily diff dot dev, link hieronder.

Zou ik een herhaal-knop verzenden met dit contract?

2:39 Oordeel, under the hood. SHIP IT. Ik zou stabiele sleutels verzenden met begrensde herhalingen en afstemming, zodat klanten koffie krijgen zonder je gedistribueerde systeemeducatie te financieren. En dat is de diff voor vandaag. Ik ben Niko van Axrisi. Verantwoord samenvoegen.

Bronnen

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