Stripeは応答が消えてもリクエストを記憶しています

この動画の要点

• べき等性は、操作を繰り返すことによって意図される効果に関係します。Stripe API v1は、文書化された保存済み応答のリプレイ契約を追加します。
• 同じ論理アクションの再試行では、同じキーとパラメーターを使用します。操作キーは、個別のSDK呼び出しやアプリケーションの再起動を超えて永続化します。真に新しいアクションには独自のキーが必要です。
• エンドポイントの実行が開始された後、Stripe API v1は最初のリクエストのステータスとボディ（500エラーを含む）を保存し、再試行時にその保存された応答を返します。
• 同じキーでパラメーターを変更すると、不一致が発生します。検証の失敗と同時実行の競合は、その試行のべき等な結果を保存せず、再試行できます。
• StripeはAPI v1キーを少なくとも24時間保持し、その後は削除する可能性があります。未解決のネットワーク再試行は最初の24時間以内に制限し、その後は操作を繰り返す前に停止して調整します。
• キャッシュされた500エラーは、接続が回復した後も繰り返し再生される可能性があります。元の操作には副作用がある場合があります。その結果を確立するには、関連するオブジェクト、ダッシュボードのリクエスト、およびWebhookを使用します。
• API v2は異なるリプレイセマンティクスを使用します。キーは、メール、在庫、およびすべてのローカルデータベース操作に対して、普遍的な「厳密に1回」の配信を確立するものではありません。

翻訳されたトランスクリプト

オリジナルの英語ナレーションから翻訳されています。利用可能なオーディオとキャプションはYouTubeによって管理されています。

タイムアウトで支払いはキャンセルされましたか？

0:00 タイムアウトは支払いが失敗したことを意味すると思います。 応答が消えてもサーバーは処理を完了できます。 その結果、チェックアウトは自信を持って何も表示しません。 なぜ再試行は再び請求できるのですか？ Stripeは試行をどのように記憶していますか？ いつ再試行を停止すべきですか？ そして、1つの厄介な詳細を心に留めておいてください。 記憶されたエラーはネットワークの問題よりも長く続く可能性があります。

0:17 それについては後で説明します。 これはThe Daily Diff、Under the Hoodです。

べき等性キーは何を識別しますか？

0:21 べき等性とは、操作を繰り返すことが、一度だけ実行するのと同じ意図された効果を持つことを意味します。 べき等性キーは1つの論理アクションをラベル付けします。 StripeのAPIバージョン1は、再試行時にそのラベルを認識し、保存された応答を再生します。 コーヒーを買うことを想像してみてください。 Stripeは支払いリクエストを完了し、応答は戻ってくる途中で失われます。 顧客はスピナーを見ています。 彼らの銀行はもっと刺激的な解釈をするかもしれません。 保護されていない作成リクエストは、副作用を繰り返す可能性があります。

同じキーで再試行を安全にするにはどうすればよいですか？

0:45 最初の試行の前に一意のキーを添付し、再試行のためにそれを保持してください。 アプリケーションが再起動する場合、そのキーを操作とともに記録に保存してください。 Stripeのバージョン1 APIでは、エンドポイントの実行が開始されると、 最初のリクエストのステータスとボディが保存されます。 同じキーとパラメーターを再度送信すると、Stripeは保存された応答を返します。 領収書が再び移動する間、コーヒーはそのままです。

Stripeは何を正確に保存しますか？

1:07 これがStripeの実際の表現です。 同じキーでの再試行は、保存された応答を返します。 500エラーを含みます。 ドキュメントは、楽観的に名付けられた再試行ヘルパーよりも多くの仕事をします。 顧客は再びタップします。 あなたのアプリは、それが保留中の購入を再開するのか、それとも別の購入を開始するのかを決定します。 真に新しいコーヒーには新しいキーが与えられます。 すべてのネットワーク再試行に新しいキーを使用すると、保護が無効になります。

1:27 同じキーで異なるパラメーターを使用すると、不一致が発生します。

リクエストが変更された場合はどうなりますか？

1:30 パラメーターの検証に失敗した場合、またはそのキーを持つ別のリクエストがまだ実行中の場合、 Stripeはその試行のべき等な結果を保存しません。 これらのリクエストは再試行できます。 競合するリクエストは競合を受け取ります。 これらはバージョン1のルールです。 バージョン2は異なる動作をします。 ヘッダーはシステム全体で厳密に1回の配信を約束することはできません。 メール、在庫、およびデータベースはそれぞれ障害処理が必要です。

1:52 キーは、文書化された範囲内で操作を保護します。 Stripeはバージョン1のキーを少なくとも24時間保持し、その後は削除する可能性があります。

記憶された結果はどのくらいの期間再試行しても安全ですか？

1:59 削除されたキーは新しいリクエストを実行できます。 未解決の再試行は最初の1日以内に留めてください。 それ以降は、停止して元の結果を調整してください。 サーバーに余裕を与えるために、指数関数的バックオフとジッターを使用してください。 そうしないと、再試行が燃えているコーヒーショップの外に列を作ります。 Stripeのライブラリは再試行を処理しますが、ライブラリのデフォルトを確認してください。 その厄介なエラーが問題です。

なぜ記憶されたエラーは何度も戻ってくるのですか？

2:20 キャッシュされた500応答は、接続が回復した後も繰り返し再生され続けます。 元の操作は副作用を生じている可能性があります。 オブジェクト、ダッシュボード、およびWebhookを使用してその結果を解決してください。 新しいキーはアクションを繰り返すことができます。 私が話すのを聞くよりもこれを読みたい場合は、diffが毎日朝、あなたの受信トレイに届きます。 daily diff dot devで無料で、リンクは下にあります。

この契約で再試行ボタンをリリースしますか？

2:39 評決、Under the Hood。 Ship it。私は安定したキーと、制限された再試行と調整を出荷します。 そうすれば、顧客はあなたの分散システム教育に資金を提供することなくコーヒーを手に入れることができます。 そして、それが今日のdiffです。 AxrisiのNikoです。 責任を持ってマージしてください。

情報源

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