順序どおりに届かないWebhookイベントを処理する

Webhookの到着順は状態の順序を保証しません。再試行の遅延や手動再配信により、古いペイロードが新しいイベントの後に届くことがあります。配信行の作成時刻は元の業務上の変更ではなく試行を記録します。

手順

1. 署名を検証し、最上位のイベントidで重複を排除して、type、created、workspace_id、dataを解析します。イベントIDは意味を持たない値であり、並べ替えに使用しないでください。
2. 最上位のcreatedはイベントのUnix秒による発生時刻として保存し、全体の順序を示す番号として扱わないでください。別のイベントが同じ秒に発生する場合があり、再配信では古いペイロードが保持され、新しい配信行が作られます。
3. file.uploadedではdata.file_idをキーに状態を保存し、整数のdata.versionを比較します。大きいバージョンを適用し、同じイベントIDは重複として扱い、新しいものの後に届いた小さいバージョンは無視してください。
4. share.accessedではアクセスの発生にdata.accessed_atを使用し、異なるイベントIDをすべて保持してください。1つのリンクへの2回の閲覧は、時刻が近くても別々のイベントです。
5. file.deletedの現在のペイロードにはfile_id、name、permanentがありますが、対象のバージョンはありません。元に戻せない後続の削除を実行する前に、別途認可されたAPI読み取りでdosyaの現在の状態を照合してください。
6. 古いアップロードイベントを遅延させ、先に大きいファイルバージョンを処理してから古いリクエストを解放してテストします。保存済みバージョンが後退せず、両方の試行に意図した応答が返ることを確認してください。

送信側はイベント間やエンドポイント間の順序を保証しません。信頼できる項目がある場合は対象ごとに後退しない状態を保持し、ない場合は現在の状態を照合してください。

期待される結果

受信側は確認済みの最新ファイルバージョンに収束し、異なる共有アクセスを保持して、ランダムなIDや配信時刻から削除順序を推測しません。遅れて届いた再試行によって後続の状態が後退することはありません。

2つのイベントが同じcreated値を持っています。 対象固有の項目を使うか現在の状態を照合してください。エンベロープのタイムスタンプの精度は1秒です。

削除を照合できません。 元に戻せない状態変更を推測せず、そのイベントを隔離して担当者に確認を依頼し、受信側の再試行ポリシーに従って応答してください。

関連ガイド

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