複数systemを更新するworkflowが途中で失敗した場合、最初から再試行するか、済んだ変更を補償するかを、現在の状態から判断します。補償はDB transactionのrollbackと同じではありません。通知、予約、権利付与など、一度確定した外部操作は、元の値を書き戻すだけで元どおりになるとは限りません。
本稿は補償処理の設計です。実際の返金、取消、削除、workflow起動、外部更新は実施していません。以下は架空の登録workflowで、製品の復旧成功や支払判断を示すものではありません。
目次
正常処理と補償処理の二つの台帳を対応させる
operation ID、入力バージョン、step、外部record ID、実行状態、結果確認、補償方法を記録します。成功応答がないstepは「未実施」ではなく結果不明かもしれません。補償する前に、外部systemへ何が反映されたかを識別子で照合します。
表は横にスクロールできます
| 架空の正常step | 失敗時に必要な判断 | 補償候補の性質 |
|---|---|---|
| 利用申請record作成 | 申請自体を残すか | 取消状態へ遷移 |
| 利用枠を確保 | 外部で確保済みか | 対象予約IDを解放 |
| 権利を付与 | 利用開始済みか | 必要な取消・人手判断 |
| 通知 | 誰へ届いたか | 訂正案内、送信取消の可否確認 |
この表の補償候補は、自動実行してよい操作の一覧ではありません。各systemの正式API、業務規程、権限、対象状態を確認し、取消できないものや人が判断するものを区別します。
再試行・前進・補償・保留を分ける
一時的な取得失敗なら、制限内の再試行で正常経路を続けられる場合があります。取り消しができない確定操作なら、別stepで不足分を完了する方が業務上適切な場合もあります。すべてのerrorで補償を始めず、正常処理の最終状態と業務上の到達目標を先に決めます。
AzureのCompensating Transaction pattern（新しいタブで開く）は、補償が元の完全な状態へ戻すとは限らず、業務固有の規則や並行変更を考慮する必要を説明しています。たとえば過去の値で丸ごと上書きすると、別userが後から行った正当な変更を消す可能性があります。
補償対象のrecordとバージョン、実行前提を確認します。現在状態が変わっていれば自動上書きせず、衝突として保留します。「最後のstepが失敗したから最初のrecordを削除する」といった、関係者や証跡を失う処理にしないようにします。
補償の順序は、単純な逆順と決めつけない
依存関係、外部契約、整合性が重要なresourceを見て順序を決めます。公式patternも、補償が必ず正常処理の逆順とは限らず、一部を並列にできる場合を説明しています。ただし並列化してよいかは、各stepの依存と共有resourceで判断します。
表は横にスクロールできます
| 決める項目 | 記録例 | 不明なら |
|---|---|---|
| 実行前提 | 元stepの確定結果と現バージョン | 外部状態を確認 |
| 依存 | Aを補償後にBを解放 | 順序を推測しない |
| 一回性 | 元operationと補償stepのkey | 二重取消を止める |
| 期限 | 取消可能期間と担当 | 期限超過を人へ渡す |
| 終了条件 | 各resourceの許容状態 | 成功一語にまとめない |
全stepへ同じ取消APIを使うような汎用化はできません。業務意味と現在の状態を確認してから補償commandを作り、必要な理由や承認も追えるようにします。
補償自体の失敗と、結果不明を保存する
補償も外部操作なので、通信断、権限失効、競合、期限切れが起こります。公式patternは補償の進捗を残し、失敗地点から再開し、繰り返しに耐えるcommandにすることを説明しています。正常workflowの履歴だけでは足りず、補償のattemptと結果も対応させます。
補償成功後に完了記録だけ保存できなかった場合、再試行で同じ取消や通知を繰り返す危険があります。外部record ID、operation key、状態照会で確定結果を読み戻します。補償要求を送ったというlogだけで「元に戻った」と報告しません。
止める条件と、人へ渡す情報を決める
取消不能、並行変更、対象の曖昧さ、結果不明、業務上の判断が必要な場合は自動補償を保留します。alertには元operation、確定済みstep、実施した補償、残った不整合、対象ID、次の担当を含めます。secretや顧客本文を丸ごと添付する必要はありません。
AIには台帳とlogから差分候補をまとめさせられますが、未確認stepを成功・未実施へ推測分類させません。取消や支払の意思決定を自然文の推論だけで確定せず、各stepの明示的な条件と担当へ戻します。
完了条件を正常系とは別に検証する
許可された試験環境で、各step直後の停止、補償途中の停止、重複補償、結果不明、並行更新、取消期限外を条件にします。各試験で正常処理と補償の両台帳を見て、二重実行がなく、残った状態が業務上説明できるかを確認します。本稿で試験を実行したという意味ではありません。
設計変更前の状態遷移と規則を保存します。補償をさらに取り消す操作が必要な場合も、それ自体を別の業務処理として判断します。完了記録は「rollback済み」だけでなく、何を残し、何を補償し、何が人手確認中かをstepごとに示します。