HTTP 200でも内容取得に失敗する：意味検証とbaseline保護

HTTP 200、新規4件、通知なし。外部の更新ページを追う自動監視としては、一見すると穏当な完了に見えます。

しかし、保存された4件は正規ページの更新ではなく、エラーページ由来の内容でした。取得処理は応答本文を受け取れていたため例外にならず、keyword hitも0だったため通知も出ませんでした。そのまま比較用のbaselineが置き換わり、次に正規ページへ戻ったときの差分まで信頼できない状態になりました。

再検証では、正規の転送先からHTTP 200を確認し、エラーを示す印がないこと、意味のある項目が631件あることを確認しました。問題はHTTP 200ではありません。200だけを完了条件にしていたことです。

HTTP応答と内容取得を別々に検証する

自動化では、通信としての成功と、目的の情報を得た成功を分けて扱う必要があります。

第一段は、要求に対して応答を取得できたことです。HTTPステータスや本文の受信はここに含まれます。第二段は、その本文が本当に監視対象のページであり、比較や通知に使ってよい内容だと確認できたことです。

stateやbaselineを更新してよいのは、第二段まで通過した後です。HTTP 2xxは通信の成功であって、目的の情報を得た成功ではありません。

これは、更新ページを自動で追い、見逃しも誤通知も避けたい運用者のための検収条件です。クラウドの通知機能、手元のスクリプト、既存の監視サービスのいずれを使う場合でも、比較対象を更新する判断は別に置く必要があります。

HTTPステータス・意味検証・旧state保持を比べる

意味検証は、複雑な仕組みである必要はありません。少なくとも、最終的に許可した到達先へ着いたか、エラー本文を示す印がないか、対象らしい最低限の項目数があるかを確認します。必要に応じて、ページ固有の必須語、日付付きの項目、版を示す見出しも検収材料になります。

重要なのは、単一の判定に頼らないことです。最終URL、エラーの印、項目数、対象固有の要素を組み合わせると、「本文は受け取れたが目的のページではない」応答を通常の変化から外しやすくなります。

通信成功と目的達成を混同すると、失敗は静かに蓄積します。この構造は、連続SKIPを成功扱いしてしまう問題とも共通しています。処理が止まらないことだけでは、必要な結果が得られた証明になりません。

意味検証に失敗したら旧baselineを保持する

今回の失敗は、エラーページを通常の変化として保存し、baselineを汚染した点にありました。不正な応答を一度比較正本にすると、その後の正常な応答まで異常な差分に見えます。

修復後は、取得結果として要求先、最終到達先、ステータス、本文を保持し、意味検証に失敗したものをfetch_errorとして扱うようにしました。その場合は旧stateを保持します。失敗を記録しつつ、比較対象は進めないという分離です。

これは「何も起きなかったことにする」処理ではありません。次回の比較対象を壊さないための処理です。毎日成功と記録されながら必要な情報が得られていない状態は、例外を握りつぶした収集系のサイレント失敗でも問題になりました。成功記録の見栄えより、次の判断に使えるstateを守る方が重要です。

汚染されたbaselineだけを再作成する

baselineが汚染された場合、すべての監視履歴を作り直す必要はありません。今回も、汚染済みの対象だけを正規ページから再baselineしました。他の監視対象の履歴には触れず、通常の変化通知も送っていません。

これは慎重さのためだけではありません。復旧作業による差分を、読者や運用者に新しい更新として届けないためです。修復が完了したことと、監視対象に通常の変化があったことは別の出来事です。

差分監視の検収チェック

• 最終的に、許可した到達先へ着いたと確認しているか
• エラー本文や想定外のページを除外できるか
• 対象らしい最低件数や必須要素を確認しているか
• 検証に失敗したとき、旧baselineを保持できるか
• 復旧時の再baselineを通常の更新通知と分けられるか

HTTPステータスは有用な観測値です。ただし、それだけで完了を宣言するには情報が足りません。この自動化は、何をもって目的の情報を得たと判定しているか。HTTP statusだけなら、まだ完了していません。