5.5 MBのランタイムを配信するブラウザベースのPythonプレイグラウンドが、低速な接続環境のユーザーに対してサイレントに失敗し始めました。原因は、誤用されたNetwork Information APIと、問題を誤ってラベル付けしたエラーグルーピング・ダッシュボードでした。このバグは数週間にわたって潜伏し、開発者の時間を浪費させ、一部のユーザーがコードを実行できない状態を招きました。

問題が表面化した経緯

プレイグラウンドのエラートラッカーには、**「undefined is not an object.」**という、目を引くメッセージが1つ表示されていました。このタイトルは単純なJavaScriptのタイポ（打ち間違い）を示唆していたため、チームは存在しないコードパスを追いかけてしまいました。生のメタデータを調査したところ、それらのインシデントの89%は、実際にはネットワークのタイムアウトであったことが判明しました。ダッシュボードは最初に届いたエラーを採用してバッチ全体の名前として使用していたため、真の失敗の種類が隠蔽されていました。

教訓1 – ダッシュボードのタイトルは人を欺くことがある

インシデントを集計するダッシュボードは、その集計ロジックが各イベントの真の原因を反映している場合にのみ役立ちます。今回の場合、エラーの原因ではなく場所によってグルーピングしていたことが、クライアント側のバグという誤った印象を与えていました。教訓：ダッシュボードの見出しだけで問題を解決しようとしてはいけません。リソースを割り当てる前に、基礎となるイベントのサンプルを抽出し、実際に何が起きているのかを確認してください。

教訓2 – プレースホルダーの値は測定値ではない

低速な回線のユーザーに対して重いランタイムの読み込みを避けるため、コードはNetwork Information APIを参照し、毎秒メガビット数を報告するdownlinkプロパティを読み取っていました。しかし、Chromeでは初回訪問時に、実際の測定値ではなくプレースホルダーを返すことがよくあります。ロジックはそのプレースホルダーを高速な接続として扱って最適化をスキップしてしまい、結果として、助けるべき対象であったユーザー自身をブロックしてしまいました。

デフォルト値やセンチネル値（番兵値）はすべて「データなし」として扱ってください。プレースホルダーはフォールバック戦略をトリガーすべきであり、実際の通信速度として解釈すべきではありません。

教訓3 – ネットワーク状況は変化するため、単一のスナップショットは信頼できない

downlinkの問題の後、チームは接続を「4g」「3g」などに分類するeffectiveTypeのチェックに切り替えました。手短なラボテストでは合格しましたが、その直後に同じテストを再実行すると失敗しました。モバイル接続は変動します。ユーザーは、ある瞬間には高速な4G回線にいても、次の瞬間には低速な3Gに落ちることがあります。ページロード時のみ接続を確認するのはギャンブルです。

適切なアプローチは、Network Informationオブジェクトのchangeイベントを**購読（subscribe）**し、一度限りの判断を下すのではなく、帯域幅の変化に反応することです。

チームが行った変更

  • 2段階ダウンロード – ランタイムは、まず非常に小さなブートストラップファイルから開始されるようになりました。接続が低速であると判断された場合、ブートストラップが残りのランタイムを小さなチャンクに分けて取得するため、ダウンロードが完全に中断される可能性を低減します。
  • ライブモニタリング – 単一のdownlinkの読み取りではなく、コードは現在changeイベントをリッスンし、ダウンロード戦略を動的に調整します。
  • 安定したソース選択 – 以前は、より高速なエンドポイントが現れると、ダウンロードの途中でCDNを切り替えていました。低速な回線では、これによりダウンロードがゼロから再開されてしまい、問題を悪化させていました。新しいロジックでは、ダウンロードの間、ソースを固定します。
  • キャッシュ書き込みの遅延 – アプリが使用可能になる前に実行されていた重いキャッシュ操作は、ランタイムが開始された後に延期されるようになり、重要なダウンロードのための帯域幅を確保します。

より広範な影響

Webベースのツールを構築する開発者にとって、ネットワークの変動性は極めて重要な懸念事項です。低速な回線でのサイレントな失敗は、ユーザーのフラストレーションを招くだけでなく、テレメトリ（計測データ）を歪め、チームを誤ったデバッグの道へと導きます。今回の場合、データの誤解釈が数週間にわたる無益な調査を引き起こしました。

次に注意すべきこと

まとめ： データが綺麗すぎる場合は、おそらくプレースホルダーです。ダッシュボードの見出しが単一のバグを指し示している場合は、さらに深く掘り下げてください。そして、一度限りのネットワーク読み取りに基づいて決定を下すことは、動く標的に賭けているようなものです。これらの現実を考慮して調整することで、サイレントな失敗を、予測可能で回復可能なイベントへと変えることができます。