Stripe merkt sich Ihre Anfrage, wenn die Antwort verschwindet

Was dieses Video behandelt

• Idempotenz betrifft die beabsichtigte Wirkung der Wiederholung einer Operation. Die Stripe API v1 fügt einen dokumentierten Vertrag zur Wiedergabe gespeicherter Antworten hinzu.
• Ein erneuter Versuch der gleichen logischen Aktion verwendet denselben Schlüssel und dieselben Parameter. Behalten Sie den Operationsschlüssel über separate SDK-Aufrufe oder Anwendungsneustarts hinweg bei; eine tatsächlich neue Aktion benötigt ihren eigenen Schlüssel.
• Nach Beginn der Endpunkt-Ausführung speichert die Stripe API v1 den Status und den Inhalt der ersten Anfrage, einschließlich 500er-Fehler, und gibt diese gespeicherte Antwort bei Wiederholungen zurück.
• Geänderte Parameter mit demselben Schlüssel führen zu einer Nichtübereinstimmung. Validierungsfehler und Konflikte bei der gleichzeitigen Ausführung speichern kein idempotentes Ergebnis für diesen Versuch und können wiederholt werden.
• Stripe behält API v1-Schlüssel für mindestens 24 Stunden und kann sie danach löschen. Beschränken Sie ungelöste Netzwerk-Wiederholungen auf die ersten 24 Stunden, stoppen Sie dann und gleichen Sie ab, bevor Sie den Vorgang wiederholen.
• Ein zwischengespeicherter 500er-Fehler kann auch nach der Wiederherstellung der Konnektivität immer wieder abgespielt werden. Die ursprüngliche Operation kann Nebeneffekte haben; verwenden Sie das relevante Objekt, die Dashboard-Anfrage und Webhooks, um ihr Ergebnis festzustellen.
• API v2 verwendet andere Wiedergabesemantiken. Ein Schlüssel stellt keine universelle genau-einmalige Zustellung für E-Mail, Inventar und jede lokale Datenbankoperation her.

Übersetztes Transkript

Aus der englischen Originalerzählung übersetzt. Verfügbare Audio- und Untertitel werden von YouTube gesteuert.

Hat ein Timeout Ihre Zahlung storniert?

0:00 Sie denken, ein Timeout bedeutet, dass Ihre Zahlung fehlgeschlagen ist. Der Server kann beenden, während die Antwort verschwindet, und Ihr Checkout zeigt selbstbewusst absolut nichts an. Warum kann eine Wiederholung erneut belasten? Wie merkt sich Stripe einen Versuch? Wann sollten Sie aufhören, es erneut zu versuchen? Und behalten Sie ein unangenehmes Detail im Hinterkopf. Ein gespeicherter Fehler kann das Netzwerkproblem überleben.

0:17 Darauf kommen wir zurück. Dies ist The Daily Diff, unter der Haube.

Was identifiziert ein Idempotenzschlüssel?

0:21 Idempotenz bedeutet, dass die Wiederholung einer Operation dieselbe beabsichtigte Wirkung hat wie das einmalige Ausführen. Ein Idempotenzschlüssel kennzeichnet eine logische Aktion. Stripes API Version eins erkennt dieses Kennzeichen bei Wiederholungen und spielt eine gespeicherte Antwort wieder ab. Stellen Sie sich vor, Sie kaufen einen Kaffee. Stripe schließt Ihre Zahlungsanfrage ab, und die Antwort geht auf dem Rückweg verloren. Der Kunde sieht einen Spinner. Ihre Bank hat vielleicht eine aufregendere Interpretation. Eine ungeschützte Erstellungsanfrage kann den Nebeneffekt wiederholen.

Wie macht derselbe Schlüssel einen erneuten Versuch sicher?

0:45 Fügen Sie einen eindeutigen Schlüssel vor dem ersten Versuch an und behalten Sie ihn für Wiederholungen bei. Wenn Ihre Anwendung neu startet, bewahren Sie diesen Schlüssel mit der Operation in Ihren Aufzeichnungen auf. Für Stripes API Version eins, sobald die Endpunkt-Ausführung beginnt, werden der Status und der Inhalt der ersten Anfrage gespeichert. Senden Sie denselben Schlüssel und dieselben Parameter erneut, und Stripe gibt die gespeicherte Antwort zurück. Der Kaffee bleibt stehen, während seine Quittung erneut reist.

Was genau speichert Stripe?

1:07 Hier ist Stripes tatsächliche Formulierung. Wiederholungen mit demselben Schlüssel geben die gespeicherte Antwort zurück, einschließlich 500er-Fehlern. Die Dokumentation leistet mehr Arbeit als Ihr optimistisch benannter Wiederholungshelfer. Der Kunde tippt erneut. Ihre App entscheidet, ob dies den ausstehenden Kauf fortsetzt oder einen anderen startet. Ein wirklich neuer Kaffee bekommt einen neuen Schlüssel. Ein frischer Schlüssel für jede Netzwerk-Wiederholung vereitelt den Schutz.

1:27 Unterschiedliche Parameter mit demselben Schlüssel lösen eine Nichtübereinstimmung aus.

Was passiert, wenn sich die Anfrage ändert?

1:30 Wenn Parameter die Validierung fehlschlagen oder eine andere Anfrage mit diesem Schlüssel noch ausgeführt wird, speichert Stripe kein idempotentes Ergebnis für diesen Versuch. Diese Anfragen können wiederholt werden. Eine konkurrierende Anfrage erhält einen Konflikt. Dies sind Regeln der Version eins. Version zwei verhält sich anders. Ein Header kann keine genau einmalige Zustellung über Ihr System hinweg versprechen. E-Mail, Inventar und Ihre Datenbank benötigen jeweils eine Fehlerbehandlung.

1:52 Der Schlüssel schützt die Operation innerhalb ihres dokumentierten Umfangs. Stripe behält Version eins Schlüssel für mindestens 24 Stunden und kann sie danach löschen.

Wie lange ist das gespeicherte Ergebnis sicher für einen erneuten Versuch?

1:59 Ein gelöschter Schlüssel kann eine neue Anfrage ausführen. Halten Sie ungelöste Wiederholungen innerhalb des ersten Tages. Darüber hinaus, stoppen Sie und gleichen Sie das ursprüngliche Ergebnis ab. Verwenden Sie exponentielles Backoff und Jitter, um dem Server Luft zu verschaffen. Andernfalls bilden Wiederholungen eine Schlange vor einem brennenden Café. Stripes Bibliotheken handhaben Wiederholungen, aber überprüfen Sie die Standardeinstellungen Ihrer Bibliothek. Dieser hartnäckige Fehler ist der Haken.

Warum kann ein gespeicherter Fehler immer wieder auftauchen?

2:20 Eine zwischengespeicherte 500er-Antwort wird auch nach der Wiederherstellung der Konnektivität immer wieder abgespielt. Die ursprüngliche Operation kann Nebeneffekte erzeugt haben. Lösen Sie ihr Ergebnis mithilfe von Objekten, dem Dashboard und Webhooks. Ein neuer Schlüssel kann die Aktion wiederholen. Wenn Sie dies lieber lesen als mich sprechen zu hören, landet der Diff jeden Morgen kostenlos in Ihrem Posteingang unter the daily diff dot dev, Link unten. kostenlos unter the daily diff dot dev, Link unten.

Würde ich einen Wiederholen-Button mit diesem Vertrag ausliefern?

2:39 Urteil, unter der Haube. SHIP IT. Ich würde stabile Schlüssel mit begrenzten Wiederholungen und Abgleichungen ausliefern, damit Kunden Kaffee bekommen, ohne Ihre Ausbildung in verteilten Systemen zu finanzieren. Und das ist der Diff für heute. Ich bin Niko von Axrisi. Verantwortungsbewusst zusammenführen.

Quellen

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