この章の答え
要求・永続状態の変更・返答・通知が、同じ意味でつながることを検証する。
TUI のテストとサーバーのテストがそれぞれ通っていても、間の約束がずれていると利用者の操作は壊れます。thread/revert を題材に、何を変更し、何を返す API なのかを具体化します。
01|図でつかむ
返答と通知の順序や内容はテスト対象。図は固定の配信順を保証するものではない。
02|3つのポイントで理解する
1. 何を戻す操作かを明確にする
確認した ThreadRevertParams は、指定 turn より前の保存済み会話履歴へ置き換える操作です。ファイルの変更を元に戻す操作ではありません。この区別が契約の中心です。
2. 応答だけで履歴がそろうかを見る
確認した型の説明では、返す thread の turns は空で、保持された履歴は一覧 API から取得します。応答にすべての turn が入ると思い込むと、UI の復元が不完全になります。
3. 失敗時の状態も契約に含める
不正な対象を指定したとき、エラーだけでなく保存状態がどう残るかを確かめます。成功時は通知と再取得が同じ履歴を示すかを見ます。
03|ソースで確かめる
以下の検索は Codex リポジトリのルートで実行します。最初に対象 commit を記録し、検索結果から定義と呼び出し元を一つずつ開いてください。
git rev-parse --short HEAD
rg -n "ThreadRevertParams|ThreadRevertResponse" codex-rs
読む入口: codex-rs/app-server-protocol/src/protocol/v2/thread.rs 。リンク先は照合に使った固定 commit のファイルです。手元の版と異なる場合は、上の検索語から探し直します。
小さく試す
ThreadRevertParams と Response のコメントを読み、入力、変更対象、返答、再取得の必要性を四行で整理します。
04|30秒で復習
- API が何を変更するかを明確にする。
- 応答にない情報は別途取得する。
- 成功と失敗の両方で保存状態を確認する。