ブラウザ自動化のネットワーク監視が request-failed や ERR_ABORTED を報告しても、それだけでアプリやサーバーの障害とは判定できない。先読み中のリクエストを画面遷移でブラウザがキャンセルした場合や、ナビゲーションが古いリクエストを打ち切った場合にも同じシグナルが出る。特にリンク先を先読みするフレームワークを、複数ページへ連続遷移するQAシナリオで動かすと発生しやすい。

判定手順

1. issue のURL・発生時点・直前の画面遷移を確認し、文書本体、XHR/fetch、先読みリソースのどれかを分類する。
2. 同時刻のサーバーログまたはプロキシログで、そのURLが実際に何statusで処理されたかを照合する。サーバーが2xxを返していて、ブラウザ側だけがキャンセルしているならHTTP障害ではない。
3. page error、console error、4xx/5xx、操作失敗、表示欠落が併発していないかを確認する。キャンセルだけで画面遷移と主要要素の検証が完了している場合は、実装不具合ではなく監視上の偽陽性として分ける。
4. 動画やスクリーンショットで最終表示も確認し、ネットワーク監視の単一シグナルだけで合否を決めない。

運用上の判断

QAツール側では request-failed を消して成功扱いにするのではなく、キャンセル理由やresource type、対応するサーバーstatusを合わせて記録し、server failure と client cancellation を別カテゴリにする。実装側をテスト都合で変更して先読みを止めるのは、実ユーザーへの効果がない限り避ける。

この判定は、Playwright等でSPA/SSR/静的exportを巡回するE2Eや、先読み・ストリーミング・ナビゲーション競合があるブラウザQAに適用できる。