受信側の停止後にWebhook配信を復旧する

受信側の復旧には、今後の配信を再開することと、過去の失敗イベントのうち再配信がまだ必要なものを判断することの2つがあります。エンドポイントを再度有効にしても、最終状態になった保留分は自動で処理されません。

手順

1. 公開HTTPS受信側を復旧し、現在の署名シークレットで検証し、イベントを永続的に確定して、dosyaの10秒のタイムアウト内に2xxを返せることを確認してください。
2. 連携 → Webhookでエンドポイントを探します。長く続いた問題では配信が繰り返しできなかったため、自動で無効化されました。、失敗した試行の回数、無効化時刻、再度有効化が表示されます。
3. エンドポイントがまだ無効な間にテストイベントを送信を選択してください。テストルートはactiveがfalseでも実際の署名付きリクエストを送信します。待機中のトーストだけを信じず、配信を開いて新しい行に成功が表示されるまで待ってください。
4. それを確認してから再度有効化を選択します。更新によりconsecutive_failuresとdisabled_atはクリアされますが、すでに失敗と表示された配信は変わりません。
5. 過去の行を新しい順に確認し、受信側にまだ必要な業務イベントだけに再配信を選択してください。各再配信は新しい配信IDを持ちますが、元のイベントIDとペイロードを保持するため、イベントIDによる重複排除を有効にしておく必要があります。
6. 制御された購読イベントを1件発生させ、通常の成功を確認します。復旧した業務上の状態を1回確認し、意図的に再配信しなかった失敗イベントを記録してください。

配信の試行は最大6回です。最初の試行に続き、30秒、2分、10分、1時間、6時間後に予定されます。エンドポイントで十五回連続の試行が失敗すると無効になります。その後10分ごとの健全性確認で、そのエンドポイントに残る保留行がendpoint auto-disabled after sustained delivery failure付きの失敗としてマークされます。各確認では健全でないエンドポイントを最大50件調べるため、大規模な問題ではすべての無効なエンドポイントのキューが最終状態になるまで後続の確認が必要な場合があります。

期待される結果

今後の通信を再開する前に、修復された受信側が制御されたテストに成功します。再有効化で障害のカウンターがクリアされ、手動で選んだ過去のイベントは後続の変更を重複させずに復旧されます。

再有効化後も失敗行が失敗のままです。 想定どおりの動作です。業務上の影響を確認してから、そのイベントに再配信を使用してください。

テストは成功しますが、新しいイベントが届きません。 カードが有効であり、目的のイベントバッジが選択されたままで、イベントを発生させる操作が同じワークスペースで行われたことを確認してください。

関連ガイド

• Webhook署名を検証する
• 配信を確認する