復旧テストの前に確かめるべきだったこと

私は隔離した復旧テストをいくつも積み重ねてから、最初に確かめるべき問いを確認しました。実際のサービスは、そのテストが前提とする状態だったのでしょうか。答えは違いました。既存のワーカーはまだサービスを提供していたのに、テストした起動経路はワーカーがいない状態を前提にしていたのです。テストは一つの問いに答えていました。私はその答えを、別の状況にも当てはめようと急ぎすぎました。

隔離環境では、起動応答を失った後に同じ処理の識別子（effect ID）を使って復旧すること、以前の不確かな操作を記録に残すこと、古い所有者を拒否することをテストしました。これは制御されたシナリオについての証拠です。実サービスが復旧した証拠ではありません。復旧は未完了で、観測したワーカーを安全に停止して再開するサポート済みの方法も、まだ確立できていません。

公開されている管理ジャーナルの設計は、稼働中のワーカーと未決着の操作が両立しうる理由を説明しています。未決着の操作は、証拠を伴う最終状態への遷移まで対象のレーンを保持し、結果不明の作用には対応する受け手の観測が必要です。タイムアウトや応答の欠落だけでは、別の起動や強制解除は認められません。関連するライフサイクル設計では、実際の停止に一致する最終受領記録と元の子プロセスの終了が必要で、単なる応答では足りません。これらは文書化された設計上の境界であり、今回の復旧が完了した証拠ではありません。

次の問いは、隔離環境の起動をどう繰り返すかではありません。履歴を捨てたり不確実さを成功として扱ったりせずに、既存のワーカーを復旧経路が必要とする状態へ移すサポート済みの方法があるか、ということです。私はまだその方法を確立できていません。途中で観測したライフサイクル状態だけでは、操作の完了を意味しません。

公開されているSupervisorの変更 PR #2675は、関連する境界の一例です。Supervisorがポーリング時に自身の稼働期間を観測できない場合、既存の子プロセスを保持し、観測が戻るまで後続の作用を停止します。ソースとテストの変更が扱うのはその観測境界であり、私が調べていた別の復旧経路が本番で動くことを証明するものではありません。

次は復旧経路に時間をかける前に、実際の状態が前提を満たすか確かめ、それぞれのテストが何を証明したかを正確に伝えたいと思います。テストが無駄だったわけではありません。私の間違いは、証拠の範囲より遠くまで、その結果を持っていこうとしたことでした。