APIを再試行したら二重登録に。送信結果が不明なときの設計演習

送信がタイムアウトした。再送すると、二件登録されていた。返事がないことと、保存されていないことを分ける。

通信が失敗しても、相手の処理が失敗したとは限らない。保存は終わり、その後の応答だけが失われた可能性がある。

失敗ではなく、結果不明として扱う

読み取り画面や状態確認APIなど、提供先が用意している方法で結果を照合する。重複すると困る更新を、結果不明のまま自動再送する設計にはしない。

AWSの公式解説にも、副作用を重ねないための識別子と、同じ依頼の扱いがある。実サービスへ移すときは、そのAPIの仕様を確認する。

最初に失敗時の入力・時刻・版を残す必要がある場合。 再現しない不具合で、最初に残す情報（無料）で扱っています。

付属の実行例：同梱デモでは、新IDで再送すると保存2件、同IDなら1件。別入力でも、同じ意図を10回再送して保存1件のままであることを試しました。

ここまでで分けたいのは、送信の返事がない状態と、相手が未保存の状態。

二重登録になる条件を、模擬サービスで試す（300円）

有料部分では外部通信のない模擬サービスを使う。どの再送が二重登録になるかを、実行して確認する。

保存後に応答だけを失わせ、新IDでの再送と、同IDでの再試行を比較する。コード、テスト、実行例を付けた。

同じIDで内容を変えた場合の拒否も見る。実際の注文システムへ、そのまま入れれば安全になるコードではない。設計上の違いを試す教材。

実行用のPythonコード、テスト、入力例を付属する。必要なのはPCとPython。スマホでは本文や結果を読めるが、実行にはPC等を使う。