この章の答え
古い修正を移す前に、状態の所有者と失敗時の保証を読み直す。
原稿では Fork から Revert への変更を題材に、以前の一行修正をそのまま移してよいかを考えています。処理名が似ていても、新しい会話を作る操作と既存の履歴を変える操作では、守るべき状態が異なります。
01|図でつかむ
歴史的な原稿の設計比較。現在の main が必ず同じ移行状態にあるという意味ではない。
02|3つのポイントで理解する
1. 修正が守っていた条件を書き出す
古い処理で、失敗時に元の thread が使える、キューの内容が有効である、といった前提が何だったかを明確にします。コード一行ではなく前提を移植の単位にします。
2. 状態変更の位置を比べる
新しい処理が履歴や入力キューをどこで変えるかを追います。変更前の失敗と、一部を変更した後の失敗では、同じ回復処理を呼べるとは限りません。
3. 無効になった入力を送り出さない
古い会話状態に結び付いた待機入力を、そのまま新しい状態へ送ってよいかを調べます。クリアや再構築の責務を確認し、重複送信・誤った文脈への送信を検討します。
03|ソースで確かめる
以下の検索は Codex リポジトリのルートで実行します。最初に対象 commit を記録し、検索結果から定義と呼び出し元を一つずつ開いてください。
git rev-parse --short HEAD
rg -n "ForkSessionForPromptEdit|thread_revert" codex-rs
読む入口: codex-rs/app-server/src/request_processors/thread_processor.rs 。リンク先は照合に使った固定 commit のファイルです。手元の版と異なる場合は、上の検索語から探し直します。
小さく試す
旧処理と新処理について、失敗前に変える状態、失敗後に残る状態、再開のきっかけを表にします。
04|30秒で復習
- 修正の成立条件を先に書く。
- 状態変更の前後で失敗を分ける。
- 残った入力が今も有効か確かめる。