複数の write を順に実行するフローで、最初の write が外部副作用を作り、後続の状態更新が失敗し得る場合、通常の再実行だけに頼ると同じ副作用を二重に作るリスクがある。

判断基準

• 最初の write が成功した時点で生成された resource ID を、後続失敗時の error response や structured result に含める。
• 再実行時はその resource ID を明示的に受け取り、最初の write をスキップして後続の紐付け・状態更新だけを再実行できるようにする。
• 後続 write 側は、同じ resource ID で既に完了済みの request を受けた場合に成功扱いにする。これにより「サーバー側では成功したがクライアントには失敗に見えた」ケースも安全に回復できる。

向いている条件

完全な単一 transaction に寄せるには既存境界の再設計が大きいが、短期的に重複副作用を避けたい場合に有効。将来的に atomic endpoint を作る余地は残しつつ、まず再実行可能性と復旧情報をレスポンス契約として固定する。

避けるべき設計

• 後続 write 失敗時に単なるエラーだけを返し、作成済み resource ID を失う設計。
• 再実行時に最初の write からやり直す設計。
• 先に状態だけ完了扱いにしてから外部副作用を作る設計。外部副作用が失敗すると完了状態だけが残る。