Sebuah playground Python berasaskan pelayar yang menghantar runtime bersaiz 5.5 MB mula gagal secara senyap bagi pengguna dengan sambungan perlahan. Punca utamanya adalah penggunaan Network Information API yang salah dan papan pemuka (dashboard) pengelompokan ralat yang tersalah melabel masalah tersebut. Pepijat ini tersembunyi selama berminggu-minggu, membazirkan masa pembangun, dan menyebabkan sebahagian pengguna tidak dapat menjalankan kod.

Bagaimana masalah ini muncul

Penjejak ralat playground tersebut memaparkan satu mesej tunggal yang menarik perhatian: “undefined is not an object.” Tajuk tersebut mencadangkan ralat taip (typo) JavaScript yang mudah, jadi pasukan tersebut mengejar laluan kod yang tidak wujud. Apabila mereka memeriksa metadata mentah, mereka mendapati bahawa 89% daripada insiden tersebut sebenarnya adalah masa tamat rangkaian (network timeouts). Papan pemuka tersebut telah mengambil ralat pertama yang tiba dan menggunakannya untuk menamakan keseluruhan kelompok, sekali gus menyembunyikan jenis kegagalan yang sebenar.

Pengajaran 1 – Tajuk papan pemuka boleh mengelirukan

Papan pemuka yang mengumpulkan insiden hanya membantu jika logik pengumpulannya mencerminkan punca sebenar setiap peristiwa. Dalam kes ini, pengelompokan mengikut lokasi dan bukannya mengikut punca ralat telah memberikan gambaran palsu tentang pepijat di bahagian klien (client-side). Pengajarannya: jangan sesekali membaiki masalah hanya berdasarkan tajuk papan pemuka. Ambil sampel peristiwa asas dan sahkan apa yang sebenarnya berlaku sebelum anda memperuntukkan sumber.

Pengajaran 2 – Nilai placeholder bukanlah ukuran

Untuk mengelakkan pemuatan runtime yang berat bagi pengguna dengan sambungan lembap, kod tersebut merujuk kepada Network Information API dan membaca sifat downlink, yang melaporkan megabit sesaat. Pada kunjungan pertama, Chrome sering mengembalikan nilai placeholder dan bukannya ukuran sebenar. Logik tersebut menganggap placeholder itu sebagai sambungan pantas dan melangkau pengoptimuman, yang akhirnya menyekat pengguna yang sepatutnya dibantu.

Anggap sebarang nilai lalai (default) atau nilai sentinel sebagai “tiada data.” Sesuatu placeholder sepatutnya mencetuskan strategi sandaran (fallback), bukannya ditafsirkan sebagai bacaan kelajuan sebenar.

Pengajaran 3 – Keadaan rangkaian berubah, jadi satu tangkapan (snapshot) tunggal tidak boleh dipercayai

Selepas isu downlink, pasukan beralih kepada menyemak effectiveType, yang mengkategorikan sambungan sebagai “4g”, “3g”, dan lain-lain. Ujian makmal yang pantas berjaya, tetapi ujian yang sama apabila dijalankan semula beberapa saat kemudian telah gagal. Sambungan mudah alih sentiasa berubah-ubah; seorang pengguna boleh kelihatan menggunakan sambungan 4G yang pantas pada satu saat dan turun ke 3G yang lebih perlahan pada saat berikutnya. Menyemak sambungan hanya semasa pemuatan halaman adalah satu perjudian.

Pendekatan yang betul adalah dengan melanggan (subscribe) kepada acara change pada objek Network Information dan bertindak balas terhadap sebarang perubahan dalam lebar jalur (bandwidth) daripada membuat keputusan sekali sahaja.

Apa yang telah diubah oleh pasukan

  • Muat turun dua peringkat – Runtime kini bermula dengan fail bootstrap yang sangat kecil. Jika sambungan dikenal pasti sebagai perlahan, bootstrap akan mengambil baki runtime dalam cebisan kecil, sekali gus mengurangkan risiko pembatalan sepenuhnya.
  • Pemantauan langsung – Berbanding hanya satu bacaan downlink, kod kini mendengar acara change dan melaraskan strategi muat turun secara langsung (on the fly).
  • Pemilihan sumber yang stabil – Sebelum ini, sistem menukar CDN di tengah-tengah muat turun apabila titik akhir (endpoint) yang lebih pantas muncul. Pada sambungan perlahan, ini menyebabkan muat turun bermula semula dari sifar, yang memburukkan lagi masalah. Logik baharu mengunci sumber sepanjang tempoh muat turun.
  • Penulisan cache tertangguh – Operasi cache yang berat yang dijalankan sebelum aplikasi boleh digunakan kini ditangguhkan sehingga selepas runtime bermula, bagi membebaskan lebar jalur untuk muat turun kritikal.

Kesan yang lebih luas

Bagi pembangun yang membina alatan berasaskan web, kepelbagaian rangkaian adalah kebimbangan utama. Kegagalan senyap pada sambungan perlahan mengecewakan pengguna dan memesongkan telemetri, yang membawa pasukan ke laluan penyahpepijatan (debugging) yang salah. Dalam kes ini, salah tafsir data telah menyebabkan penyiasatan yang sia-sia selama berminggu-minggu.

Apa yang perlu diperhatikan seterusnya

Pengajaran: Apabila data kelihatan terlalu bersih, ia mungkin sekadar placeholder; apabila tajuk papan pemuka menunjukkan satu pepijat tunggal, selidiki dengan lebih mendalam; dan apabila anda membuat keputusan berdasarkan satu bacaan rangkaian sahaja, anda sebenarnya sedang bertaruh pada sasaran yang sentiasa berubah. Menyesuaikan diri dengan realiti ini akan mengubah kegagalan senyap kepada peristiwa yang boleh diramal dan dipulihkan.