要約

  • StripeのAPI v1では、実行が始まったPOSTの最初のステータスと本文を、500も含めて保存する。同じ冪等キーの再試行は、記録が残る間、その応答を返す。
  • 500の後でも副作用が生じた可能性がある。Stripeが復旧中にオブジェクトを照合してwebhookを送っても、保存済み応答は変わらない。API v2の再試行は別の仕組みだ。

エラー票は経過報告ではない

アプリが500を受け、同じ冪等キーで再送する。二度目も500。画面には失敗が二件並ぶが、API v1の二件目は最初の応答の再生かもしれない。Stripeはエンドポイントの実行開始後に結果を保存する。Idempotent-Replayed: trueが付けば、その応答は再生だ。HTTP件数だけでは、実際に何件の業務操作が失敗したかは分からない。

Stripeは500の結果を未確定と扱う。操作に副作用があった可能性があり、障害復旧の過程で作られたオブジェクトについてwebhookが届く場合がある。保存された500はその後も赤いまま。照合が必ず完了するわけでもない。応答の色とオブジェクトの有無を別々に記録し、最後に同じ業務単位へ結び直す必要がある。

その結び目は最初の呼び出し前に作るローカル操作IDだ。リソースのメタデータに入れておけば、後から届くwebhookを元の注文に対応させられる。500の後は関連オブジェクト、Dashboardの要求記録、署名を検証したwebhookを確認する。未解決のまま新しい冪等キーを切れば、別の操作を始める可能性がある。

API v2ではStripeの説明が変わる。成功済みの操作を繰り返さず、失敗または部分失敗した作業を可能な限り完了させ、更新された結果を返す。v1からの移行で再試行ボタンの意味まで変わる。どのAPI契約で処理した要求かを先に特定するのが、復旧判断の出発点だ。

出典