Webhookの配信を安全に再試行する

dosyaの合計6回の配信試行スケジュールに対応し、イベントIDによるトランザクションの冪等性を実装して、繰り返されたリクエストが後続の状態を1回だけ変更するようにします。

再試行は通常の配信動作です。受信側は1つのイベントが複数回実行されても安全に処理できるようにする必要があります。dosyaの業務処理における変わらない識別子はイベントIDです。配信IDは試行レコードを識別し、手動再配信時には変わる場合があります。

手順

生の本文に対してX-Dosya-Signatureを検証し、業務トランザクションに入る前にX-Dosya-Event-Idと本文のidが一致することを確認してください。
後続の変更を適用するトランザクション内で、一意制約のある冪等性テーブルにイベントIDを挿入します。復旧用に処理状態と安全な結果の参照を保存してください。
一意キーの競合時は確定済みの結果を読み、変更を繰り返さずに2xxを返します。再配信では新しい値が割り当てられるため、X-Dosya-Delivery-Idだけをキーにしないでください。
応答前に処理を永続的に確定します。確定前に受信側が停止した場合は安全に再試行できます。副作用とその記録を別々に確定すると、次の試行で状態が重複する余地が生じます。
失敗時の処理を1回テストしてください。dosyaは初回を送信し、失敗が続く間は30秒、2分、10分、1時間、6時間後にさらに5回を予定します。再試行の確認処理は各予定時刻より後に実行される場合があります。
再試行を成功させて配信を確認します。業務上の結果が1件、共通のイベントID、試行回数、次の再試行がない成功を確認してください。

2xxが返されると再試行は終了します。2xx以外のレスポンス、ネットワークエラー、許可されないリダイレクト、10秒のタイムアウトはエンドポイントの連続失敗カウンターを増やします。そのような試行が15回失敗するとエンドポイントは自動的に無効になります。

同じイベントの繰り返されたリクエストは、意図した後続の結果を1件作成するか、その確定済みの結果を返します。配信試行を確認しながら、業務操作を追加で発生させずに済みます。

処理が2回発生しました。 冪等性の取得と変更を1つの原子的な境界に移し、イベントを再配信する前に既存の重複を修正してください。

処理できないイベントが繰り返し再試行されます。 検証済みのペイロードを永続的に隔離し、意図した応答方針を選んでください。失敗を返すと合計6回の試行を消費し、自動無効化のカウントにも加わります。