APIの応答が途切れたら再送してよい？二重作成を避ける確認

作成処理を送った後に応答を受け取れないと、失敗したように見えても相手側では処理済みかもしれません。結果が不明な状態と、未実行が確認できた状態を分けます。

再送する前に読む資料

通信の公開仕様では、非冪等な要求を自動で再試行する際の条件に注意が示されています。同じ要求の繰り返しで結果が重複し得る処理は、応答がないだけで未実行と判断しません。

状況を整理する

これは切り分けの例です。通信エラーの文字だけで全状態を判定しません。取得できる記録と対象の状態を照合します。

作成済みかを調べる

既存の処理に識別子や重複確認があるなら、その設計を確認します。記事なら作成先に同じ識別のものがあるかを調べます。ただし題名が似ているだけで同一と決めず、処理が使う識別方法に合わせます。

再試行の前提

再送しても重複を起こさない仕組みがあるか、同じ操作に適用されるかを確認します。独自に識別子を付けただけで、相手側がそれを使うとは限りません。公開された仕様や実装の確認なしに、安全な再送だと保証しません。

作業記録の型

対象操作：［操作］。応答：［確認できた状況］。
作成先の状態：［確認結果・未確認］。
重複防止の確認：［根拠］。
次の対応：［再送・調査・待機］。

未確認を失敗へ置き換えず、そのまま残します。複数回実行した場合は試行ごとの結果を記録します。

結果がすでに存在する場合

架空の例として、応答が途切れた後に同じ識別の作成結果を確認できたなら、再送する前にその内容と状態を照合します。存在するだけで正しく完成しているとは限りません。別の試行が作ったものかも確認し、重複や不一致があれば、追加作成より先に現在の状態を整理します。

関連する管理

試行と成功の記録と公開後の状態確認を合わせると、操作の結果を追いやすくなります。