ITSUKI.
技術779 文字2 分

Day 24|修正の移植 — 同じ一行でも、前提が変わる

#Codex#ソースコードリーディング#図解

この章しょうの答こたえ

古ふるい修正しゅうせいを移うつす前まえに、状態じょうたいの所有者しょゆうしゃと失敗時しっぱいじの保証ほしょうを読み直よみなおす。

原稿げんこうでは Fork から Revert への変更へんこうを題材だいざいに、以前いぜんの一行いちぎょう修正しゅうせいをそのまま移うつしてよいかを考かんがえています。処理しょり名めいが似にていても、新あたらしい会話かいわを作つくる操作そうさと既存きぞんの履歴りれきを変かえる操作そうさでは、守まもるべき状態じょうたいが異ことなります。

01|図でつかむ

図24|修正の移植

歴史的れきしてきな原稿げんこうの設計せっけい比較ひかく。現在げんざいの 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秒で復習

  • 修正しゅうせいの成立条件せいりつじょうけんを先さきに書かく。
  • 状態じょうたい変更へんこうの前後ぜんごで失敗しっぱいを分わける。
  • 残のこった入力にゅうりょくが今いまも有効ゆうこうか確たしかめる。

全ぜん30章しょうの目次もくじへ