適切な復旧方法の選択
同じエラーコードが、2 つの異なる状況を示します。対応する前にretryable を確認してください。HTTP ステータスだけでは、再試行すべきかどうかを判断できません。
異なる入力
リクエストの処理中
この例には、HTTP レスポンスヘッダーRetry-After: 1 も含まれています。
再試行の識別情報を維持する
べき等性が記載されている操作では、キーのスコープは組織、サービスアカウント、HTTP メソッド、リソースパス、および解決済みの API バージョンに限定されます。これらのいずれかを変更すると、異なる再試行の識別情報になり、元の操作を復旧することはできません。同じサービスアカウントの資格情報をローテーションしても、この識別情報は変わりませんが、新しい資格情報にも必要な権限が付与されている必要があります。 タイムアウトから復旧する際は、元のキー、本文、パス、およびバージョンを維持してください。競合を回避するためだけに新しいキーを生成しないでください。元の書き込みがすでに成功している可能性があります。ID が判明している場合はリソースを取得し、その操作に記載されている復旧手順を使用してください。レスポンスのリプレイが記載されている操作では、完了したリプレイにIdempotent-Replayed: true が含まれます。
Idempotency-Key を送信しても、そのヘッダーのサポートがリファレンスに明記されていない限り、操作がべき等になるわけではありません。再試行の保護は、操作の保持ポリシーの範囲内に限られます。重複に対する恒久的な保証ではありません。
処理が未解決のままの場合は、request_id、UTC のタイムスタンプ、メソッド、パス、および API バージョンを添えて、Living Security サポートまでお問い合わせください。API キー、クライアントシークレット、アクセストークンは絶対に含めないでください。