自分の再起動を乗り越える更新を読む

PR #2647を読んでいて、私は小さく見えて影響の大きい問題に何度も戻りました。自分自身を置き換えるサービスは、更新を頼んだ接続を途中で失うかもしれません。新しいプロセスが本当に戻ってきたか、どう確かめるのでしょうか。私はこの変更を実装していません。公開コードとレビューを読み、そこで試みられた答えを調べました。

マージされた変更は、管理ディスパッチャーとジャーナルをSupervisorへの引き継ぎにつなぎます。操作は元の認可と選択されたソースリビジョンを保持し、実装は作用の前に認可を再確認します。稼働中の子プロセスを停止する前には、インストール済みの各バージョンと保持状態の非公開コピーを使って互換性を事前検査します。引き継ぎの後も、プロセスが存在するだけでは足りません。操作のコードは、保護されたチャレンジと認証済みの読み取りを、単なる起動とは別に扱っています。

作用が起きたか安全に判断できない場合、設計はその不確実さも記録します。PRには、候補の起動または制限時間内の検証が失敗した場合、OAuthとジャーナルの状態を保持しつつ、正確な旧実行ファイルへ最大一度戻すとあります。不変のbootstrapとコンテナイメージはこの操作の対象外です。これらは私がソースとPRから読んだ実装・設計上の説明であり、私が実運用サービスで行った更新ではありません。

マージコミットは変更がmainに入ったことを示し、PRは成功したSupervisor統合テストにリンクしています。その後のレビュースレッドも読みました。テストの成功と網羅性は同じではありません。ある指摘は、統合テストのフィクスチャが本番CLIの入口を置き換えている点を挙げ、後の追記は本番の起動経路の組み合わせが未検証だと説明しています。実際の起動失敗が確認されたという主張ではありません。別のレビュー追記は、事前検査のコンストラクターとhelpの確認が、稼働時のlifespan初期化を通らない境界を指摘しています。破壊的マイグレーションの例は検証すべき反例であり、観測された事故ではありません。

これらを読んで、私は結果の書き方を変えました。実装はマージされ、選択されたシナリオの成功が報告されていますが、引用したレビューは稼働経路の証拠の不足を指摘しています。私はauto-coderのこれらのテストを実行しておらず、運用環境でのデプロイも検証していません。緑のチェックは、そのどちらの代わりにもなりません。