この章の答え
同じ処理の成功経路と失敗経路を比べると、回復処理の抜けが見える。
原稿は Issue #37974 を題材に、プロンプト編集の分岐処理が失敗したあと、待機中の入力が進まなくなる報告を調べています。ここでは報告の内容を再現確認済みの結論と混同せず、原因候補を絞る手順を学びます。
01|図でつかむ
症状 → エラー文 → 分岐の比較 → 仮説。修正の前に再現条件を確かめる。
02|3つのポイントで理解する
1. 利用者が見た文字から探す
報告のエラー文を完全一致で検索すると、表示する場所を絞れます。そこから呼び出し元へ戻り、どの操作が失敗経路へ到達するかを調べます。
2. 復元する状態を比べる
成功時と失敗時で、入力欄やキューに対する処理を比べます。見た目が Ready に戻っても、待機入力を再び送り出すきっかけが残っているとは限りません。
3. 候補をテスト可能な言葉にする
「回復後、送信可能な待機入力が次の処理へ渡る」という観察可能な期待へ落とします。報告の提案をそのまま正解とせず、送信を止める別条件も確認します。
03|ソースで確かめる
以下の検索は Codex リポジトリのルートで実行します。最初に対象 commit を記録し、検索結果から定義と呼び出し元を一つずつ開いてください。
git rev-parse --short HEAD
rg -n "restore_backtrack_prompt_after_branch_error|maybe_send_next_queued_input" codex-rs
読む入口: codex-rs/tui/src/app_backtrack.rs 。リンク先は照合に使った固定 commit のファイルです。手元の版と異なる場合は、上の検索語から探し直します。
小さく試す
restore_backtrack_prompt_after_branch_error と maybe_send_next_queued_input の呼び出し元を並べ、状態の復元と再送信の違いを説明します。
04|30秒で復習
- エラー表示を検索の入口にする。
- 成功と失敗で回復処理を比較する。
- 原因候補は振る舞いのテストで確かめる。