Eventarc の再試行の特性は、そのトランスポート層である Cloud Pub/Sub の再試行の特性と一致します。詳細については、リクエストの再試行と push バックオフをご覧ください。
Eventarc によって設定されたデフォルトのメッセージ保持期間は 24 時間です（指数バックオフ遅延があります）。
Eventarc トリガーに関連付けられた Pub/Sub サブスクリプションを介して、再試行ポリシーを更新できます。
- トリガーの詳細ページを開きます。
- トピックをクリックします。
- [サブスクリプション] タブをクリックします。
Eventarc によって自動的に作成されるサブスクリプションの形式は、projects/PROJECT_ID/subscriptions/eventarc-REGION-TRIGGER_ID-sub-SUBSCRIPTION_ID です。サブスクリプションの上限の詳細については、Pub/Sub リソースの上限をご覧ください。
Pub/Sub がメッセージの配信を試み、宛先がメッセージを確認応答できない場合、Pub/Sub は最小指数バックオフ（10 秒）でメッセージを再送します。宛先がメッセージの確認応答を返さない状態が続くと、再試行が行われるまでの待機時間が増え（最大 600 秒）、その待機時間の後に宛先に対してメッセージが再送されます。
ワークフロー実行が開始するとすぐに、Workflows はイベントの確認応答を行います。
デッドレター トピック
宛先がメッセージを受信しない場合は、配信不能メッセージをデッドレター トピック（デッドレター キュー）に転送できます。デッドレター トピックには、宛先が認識できないメッセージを格納できます。デッドレター トピックは、Pub/Sub トピックの作成時や Eventarc による Pub/Sub トピックの作成時ではなく、Pub/Sub サブスクリプションを作成または更新するときに設定する必要があります。詳細については、メッセージ エラーの処理をご覧ください。
再試行が保証されないエラー
アプリケーションがイベントソースとして Pub/Sub を使用し、イベントが配信されない場合、イベントは自動的に再試行されます。ただし、再試行を保証しないエラーの場合は再試行されません。ワークフローが実行されなければ、任意のソースからワークフローの宛先へのイベントは再試行されません。ワークフロー実行が開始して、その後失敗した場合、実行は再試行されません。このようなサービスの問題を解決するには、ワークフロー内でエラーや再試行に対処する必要があります。
重複するイベント
重複するイベントがイベント ハンドラに配信される場合があります。CloudEvents 仕様により、source 属性と id 属性の組み合わせは一意と見なされるため、同じ組み合わせを持つイベントは重複と見なされます。一般的なベスト プラクティスとして、べき等イベント ハンドラを実装する必要があります。
イベント ハンドラをべき等にする
再試行可能なイベント ハンドラは、次の一般的なガイドラインに沿ってべき等にする必要があります。
- 多くの外部 API では、べき等のキーをパラメータとして指定できます。このような API を使用している場合は、イベント ID をべき等のキーとして使用します。
- べき等では再試行が安全に行われるため、at-least-once 配信でうまく機能します。したがって、信頼性の高いコードを書くための一般的なベスト プラクティスは、べき等と再試行を組み合わせることです。
- コードが内部でべき等であることを確認します。次に例を示します。
- 結果が変わらずにミューテーションが 2 回以上起こることを確認する。
- 状態を変更する前にトランザクション内のデータベース状態を照会する。
- すべての副作用がそれ自体べき等であることを確認する。
- コードとは関係なく、トランザクション チェックをサービスの外側に置きます。たとえば、指定されたイベント ID がすでに処理されたことを記録している場所の状態を保持します。
- 重複した呼び出しを帯域外で処理するたとえば、重複した呼び出しの後にクリーンアップする別のクリーンアップ プロセスを用意します。