この章の答え
失敗の位置を固定すると、回復処理を繰り返し検証できる。
偶然ネットワークが切れるのを待っても、同じ失敗を何度も再現するのは困難です。失敗を差し込む境界を選び、どこまで状態が変わったかを固定すれば、回復処理の意味を検証しやすくなります。
01|図でつかむ
失敗を起こした瞬間だけでなく、その後に作業が進めるかまで見る。
02|3つのポイントで理解する
1. 差し込む境界を決める
入力検証で失敗するのか、保存処理で失敗するのかによって、検証できる回復処理が変わります。変更前の失敗を作っているなら、変更後の失敗まで確かめたとは言えません。
2. 準備する状態の妥当性を確認する
原稿は InProgress の turn を使う演習を紹介しています。現在の実装が同じ条件で拒否するかを先に確認し、存在しない経路を無理に作らないようにします。
3. 回復後のライフサイクルを追う
エラーが表示されたあと、入力欄、履歴、キュー、次の操作がどうなるかを確認します。復元の二重実行や、あとから届くイベントとの競合も観察点になります。
03|ソースで確かめる
以下の検索は Codex リポジトリのルートで実行します。最初に対象 commit を記録し、検索結果から定義と呼び出し元を一つずつ開いてください。
git rev-parse --short HEAD
rg -n "TurnStatus::InProgress|thread_revert" codex-rs
読む入口: codex-rs/app-server/src/request_processors/thread_processor.rs 。リンク先は照合に使った固定 commit のファイルです。手元の版と異なる場合は、上の検索語から探し直します。
小さく試す
失敗直前・直後・次の入力の三時点で、変わるべき状態と変わってはいけない状態を書き出します。
04|30秒で復習
- 失敗を差し込む位置を固定する。
- 状態変更の前か後かを明確にする。
- 回復後の次の操作まで確かめる。