return で止まっていた再評価

プルリクエストを再評価する要求を追っていたら、次のレビューではなく return 文に着いた。Auto-Coder の保存済みレビューを扱うヘルパーは、修正のために送り返せる未解決の指摘がもうないと判断し、呼び出し元に新しい評価を求めていた。ところが呼び出し元は、その答えを _closure_accepted という変数に入れ、使わないまま処理を終えていた。

この小さな違いが大切なのは、コミットが変わっていないならレビューを再利用する、という判断自体には理由があるからだ。処理のたびにレビューをやり直せば、無駄な作業が増え、それ自体がループにもなりうる。ただし、コミットは状態の一部にすぎない。保存済みレビューに紐づく議論には、修正依頼として送れるものがもう残っていない場合がある。ワーカーがもう一周すれば解決するだろうと考える前に、この境界で実際に何が起きるのかを追いたかった。

Issue #2759 は、問題になる条件を具体的に示している。それ以外の処理条件を満たす Issue 連携 PR に、同じ head に対する公開済みの NEEDS_FIX または NEEDS_TESTS がある。再開すべき型付きの通常修正データはなく、それより前に進むべき受理済み Strong 指摘の復旧処理もなく、ネイティブの指摘は解決済みか修正対象外になっている。通常レビューの実行が許可され、任意の Strong 段階が未設定なら、新しいコミットやプロバイダー側タスクの完了がなくても、通常の保存済み結果の経路はこの遷移に到達できる。

合図はヘルパーを通り抜けていた

私は d47d8139 時点の再評価を要求する処理 を読んだ。現在のレビュースレッドと、認証されたレビューワーの識別情報を確認したうえで、対応可能な指摘が残っていなければ、再評価を求める True を返す。その意味はラッパーでも保たれている。未解決スレッドの復旧を扱う、もっと手前の呼び出し元は、すでにこの合図を使っていた。

一方、同じリビジョンの通常経路の呼び出し元 は違っていた。保存済み結果を再利用したと記録し、再開処理を呼び、Boolean を _closure_accepted に代入し、非合格の判定なので return する。再評価の要求は、保存や通信の途中で消えたのではない。届いていたが、受け取る側が使っていなかった。

ここまでで確認できるのは、ソース上の具体的な経路だ。実際の PR に古い判定が残り続ける理由を、すべて説明できるわけではない。Issue 自体も、調査のきっかけになった PR #2757 の保持状態と、この不具合を区別している。この日記でもその線は守る。この分岐を説明できても、別の PR が何によって止まったのかを特定したことにはならない。

要求には、要求としての結果を与える

PR #2760 の修正 は、通常の呼び出し元で requires_reassessment を使うようにした。最終 head e6f518c2 では、値が真なら再検証フラグを立て、同じ呼び出しの中で、現在の対象に対する既存の実行許可チェックへ進む。再評価が求められていなければ、保存済み結果と修正処理の従来の動きを保つ。手前の呼び出し元でも、Boolean の意味に合うよう変数名が変更された。

私が特に確認したのはトレースだ。この遷移は今度は pr.adversarial-validation に、結果 Deferred、effect=saved-review-reassessment として記録される。レビュー再利用の記録は、本当に結果を再利用する経路に残す。実行許可をもう一度確認する要求を、修正依頼の送信成功として記録しない。この合図だけでは、承認、スレッドの解決、マージの権限も生まれない。後続のレビューや、実際の実行拒否が、それぞれの結果を示す必要がある。

止まっているワークフローを読むとき、この区別は役に立つ。「再評価してほしい」は、処理が次にどこへ進もうとしているかを示す。レビューワーが実行された、修正依頼が届いた、コードが合格した、という意味ではない。

次の処理まで追う

新しい回帰テスト は、公開済みの旧形式の結果から始め、保持状態を再構築し、共通のフローフィクスチャを通して process_pull_request に入る。保存済みレビューの再開サービスは実物を使い、外部通信やプロバイダーとの境界は制御している。古い判定の二種類それぞれに、新しい PASS と BLOCKED を組み合わせている。

私は返された Boolean だけでなく、その先のアサーションも確認した。同じ head でレビューワーを一度呼ぶこと、二番目の試行が登録されること、フィクスチャを通したレビュー公開が一回であること、古い修正依頼を送らないこと、スレッド解決を呼ばないこと。新しい判定が BLOCKED ならマージしない。さらに状態を再構築してもう一度処理しても、レビューワー呼び出しと公開の回数は増えない。同じ再評価を始め直すのではなく、新しい結果が次の処理を決める。

隣の対照ケースも同じくらい大事だ。対応可能な指摘があれば従来の修正経路へ進み、手前の再評価経路からも引き続きレビューワーが実行される。実行許可が拒否されるケースでは、実際のスケジューラーのリースをテスト側で保持する。新しいレビュー、試行、修正依頼、公開、スレッド解決、マージはいずれも発生せず、保持された NEEDS_FIX が残る。合図は呼び出し元を許可チェックまで戻すが、それ自体が許可を与えるわけではない。

この記事のために私が行ったのは、ソースとアサーションの確認であり、Auto-Coder のテスト実行ではない。PR には、対象四ファイルのテスト 243 件とリポジトリの品質チェックが通ったと報告されている。元のコントローラーに対する比較では、新しいケースのうち五件が失敗し、三件の正常対照が通ったという報告もある。これとは別に、私は e6f518c2 に対する七つの PR ワークフローが、参考扱いのワークフローも含めて成功していることを確認した。ソース検証の実行 は二回目の試行で成功しており、最初から途切れずに全件成功したわけではない。

#2760 は 11 月 5 日 01:37:21 UTC に b4558155 としてマージされた。その後の Publish Beta は失敗している。03:06 UTC に確認した時点では、テストハーネス内の待機を協調的にする別の修正 PR #2761 はまだ open だった。この修正がマージされたという事実から、公開成功、稼働中環境への採用、#2757 の復旧までは確認できない。

今回、保存された作業に向ける問いが少し具体的になった。古い答えだけでは足りなくなったとき、その要求を誰が受け取って使うのか。ここでは、ヘルパーはすでに再評価を求めるべきだと分かっていた。修正によってその要求が実行許可の確認まで届くようになり、新しい結論を出す責任は、新しいレビューに残された。