待機に理由を添える

「レビュー修正は依頼済みです」という返答は、一つの問いには役立つ。この指摘を以前に渡したことがあるか、という問いだ。Auto-Coder の修正経路を読みながら、私はその次を知りたくなった。新しい作業を送らないとき、その待機について、システムはどこまで安全に説明できるのだろう。

議論には、PR 作成者からの普通の返信が残っているかもしれない。単なる了解かもしれず、追加の修正指示のつもりかもしれない。送信記録だけでは決められないし、返信があるからといってプロバイダーが停止しているとも限らない。Issue #2769 は、その不確かさを仕様に含めている。どの指摘を送るか、どの条件でマージできるかを変えずに、診断上の小さな違いを見えるようにする。

対応する PR #2767 の変更は、処理本体、実際の処理経路を通る回帰テスト、三つの文書の計五ファイルだ。私はまず分類の条件を読み、そのあとで、ローカル状態が失われても証拠を参照できるようにしたレビュー修正を追った。

三つの理由には順序がある

既存の選択規則は、レビューの先頭コメントと、その後の返信を区別している。先頭コメントは、構造化された裁定結果でない限り、レビュー指摘として扱う。PR 作成者の返信をこの経路で転送するには、認識できる修正指示の宣言が必要で、印のない普通の議論は曖昧なままにしておく。対応済みの申告を同時に修正指示とすることはできず、構造化された裁定結果は別の経路が担当する。

最終 head 00a94d94 では、既存の判断の前後に次の分類が加わった。

• 選択された実行対象の指摘がすべて送信確認済みになったとき、選択対象外の PR 作成者の返信が unclassified_same_author_reply の理由になり得る。先頭コメントではなく、認識できる修正指示の宣言、対応済みの申告、裁定用の構造を含まず、そのネイティブ識別子に確認済み・確認待ちのどちらの送信証拠もないことが条件だ。
• そうでなければ、この送信済み経路の理由は actionable_feedback_already_delivered になる。どちらも従来どおり deferred の結果を保つ。
• 実行対象の指摘が残っていても、残りがすべて未確認の永続的な送信記録で止められているなら、理由は unconfirmed_delivery_receipt になる。重複送信を抑止したまま、従来の failed という結果を保つ。

この順序は大事だ。曖昧な返信があるからといって、実行対象の送信を確認できないという説明を上書きしない。新しく送信条件を満たした指摘は、通常の送信経路へ進める。新しいラベルを付けても、議論の意味が不確かなことを、転送してよい理由には変えない。

トレースの変更 は、固定された理由と head_sha を既存の pr.repair-delegation イベントへ加える。この head は評価した PR スナップショットの値であり、新たに取得した正本の head ではない。公開用の許可リストとダッシュボードの facts 描画は既存のまま使え、スキーマ変更も要らない。コメント本文、投稿者のログイン名、プロバイダーのタスク識別子、送信記録の内容は公開診断に含めない。

最初の版が見落とし得た記録

レビューでの指摘 に、分かりやすい反例があった。PR 作成者が書いた修正指示の返信をすでに送信したあとで、その返信から修正指示のマーカーが取り除かれたとする。ネイティブのコメント識別子は変わらない。交代したワーカーにはローカルの送信記録ファイルがなくても、認証されたコントローラーが残した送信記録は PR 上に存在し得る。

最初の版は、選択された実行対象の指摘についてだけ PR 側の送信記録を探していた。編集後の返信は選択対象から外れるため、その記録を見落とし、返信を未分類と表示する可能性があった。これはレビュー対象の経路における診断の誤りであり、実環境で再送やマージ条件の迂回が起きたという観測ではない。

修正では、送信記録を探す範囲を、選択された指摘と、選択対象外の診断候補の両方へ広げた。そのうえで結果を絞り直す。実行対象の送信状態へ入れるのは、選択された識別子の記録だけだ。対象外の識別子の記録は説明の根拠に使うが、実行対象の作業として照合・永続化しない。修正後のレビュー も、この切り分けを確認している。

記録の取得には、誰を信頼するかという境界もある。送信記録のローダー が受け入れる PR 側の記録は、認証されたコントローラーのアカウントによるものだけだ。ログイン名の大文字・小文字は区別しない。他の投稿者が同じ記録文面を置いても、送信済みの証明にはならない。ここは特に参考になった。待機を説明しやすくするだけでも、誰の証拠を採用するのかを決める必要がある。

説明と、何もしないことをテストする

最終版の回帰テストは十三ケースある。GitHub とプロバイダーの入出力を制御しながら、実際の PR ゲート、修正の委譲、トレース収集、公開用の投影を通る。ローカルファイルのない状態で、信頼できるリモート記録と信頼できない記録を扱う二ケースが、レビュー後に加わった境界の確認だ。

アサーションは理由、評価対象の head、結果を確かめる。公開 facts が、安全な理由と head の二項目だけであることも要求する。待機のケースでは送信回数がゼロで、送信記録のバイト列が変わらないこと、またはファイルがない状態を保つことを確認する。PR コメントの新規投稿、レビューへの返信、スレッド解決、マージも行わない。リモート記録だけを使うケースでは、対象外の識別子が照合処理へ渡らないことも必要だ。対照となる新しい第三者の返信は、通常の引き継ぎを一回だけ起こさなければならない。

理由の文字列だけを確かめるより、この組み合わせが役に立つ。診断が正しくても、意図しない副作用があれば安全とは言えない。逆に、すべての送信を止めれば静かなケースは通るが、送るべき対照ケースで失敗する。既存の照合処理は本番の経路に残っている。ここで裏付けられるのは、これらの診断上の待機が、新たな送信や送信記録の変更を加えないという限定された主張だ。

この記事のために Auto-Coder のテストを再実行したわけではない。PR のローカル検証報告は、リモート記録の二ケースを加える前の f9dfda5 に対するもので、168 件成功、新規ケースは十一件だった。私は別途、最終版のソース CI のジョブログを確認した。00a94d94 を明示的にチェックアウトし、診断の十三ケースすべてが成功した記録があり、集計は成功 5,548 件、スキップ 24 件、選択対象外 4,605 件だった。最終 head に関連付けられた七つのワークフローはすべて成功している。その中でも、このジョブの明示的なチェックアウトによって、該当するテスト結果を、PR の仮のマージ結果だけでなく、ソースのリビジョンに結び付けられる。

#2767 は 11 月 6 日 19:54:33 UTC に e974ea34 としてマージされた。配備や実環境での復旧は確認していない。コード上で得られたのは、なぜ修正の引き継ぎが起きなかったのか、より正確に説明する手段だ。その説明は、未解決の問いを認めたまま、ユーザーに代わってひそかに答えを決めずに済む。