Tarayıcılara 5,5 MB'lık bir Python runtime gönderen bir ekip, son bir sprint sırasında kaydedilen hataların %69'unun tek bir yanıltıcı başlık altında toplandığını ve bunların %89'unun aslında ağ zaman aşımı (network timeout) olduğunu keşfetti. Yanlış raporlama, geliştiricileri yanlış hata ayıklama (debugging) yoluna sürükledi ve kullanıcıların önemli bir kısmının sessiz indirme hatalarıyla karşılaşmasına neden oldu; bu, büyük varlıklar (assets) içeren her web uygulamasının başına gelebilecek bir sorun.

Panel yanıltıcıydı

Hata izleme sistemi, olayları ilk göründükleri kod konumuna göre otomatik olarak gruplandırır. Ortaya çıkan başlık, runtime loader'da basit bir hata gibi görünüyordu, bu nedenle sprint boyunca hiç zaman aşımına uğramayan kod yollarının peşinde koşuldu. Ekip alttaki meta verileri incelediğinde gerçek tablo ortaya çıktı: Hataların çoğu aslında birer hata (bug) değil, zaman aşımını tetikleyen duraksamış ağ bağlantılarıydı.

Çıkarım: Bir hata başlığı bir kolaylıktır, teşhis değildir. Başlığın gerçekte neyi temsil ettiğini doğrulamak için periyodik olarak ham verileri derinlemesine inceleyin.

Tarayıcı bağlantı API'si bir yer tutucu (placeholder) verdi

Yavaş interneti olan kullanıcıları 5,5 MB'lık bir indirme süreciyle yormamak için geliştiriciler tarayıcının Network Information API'sine (navigator.connection) başvurdu. API, her yeni ziyaretçi için sabit 1,7 Mbps bant genişliği raporladı.

Tarayıcılar, yeni bir kullanıcı için geçmiş verileri olmadığında varsayılan bir değer döndürür. Bu varsayılan değer bir ipucudur, kesin bir hız değildir. Her yeni oturumda aynı yer tutucu göründüğünde, bu durum API'nin henüz o kitle için kalibre edilmediği anlamına gelir.

Çıkarım: Hiç değişmeyen herhangi bir ağ sinyalini kesin bir metrik olarak değil, bir yedek (fallback) olarak değerlendirin.

Tek seferlik anlık görüntüler (snapshots) güvenilmezdir

Güvenilmez bant genişliği ipucunu eledikten sonra ekip, test paketlerinde işe yarıyor gibi görünen farklı bir sinyale geçti. Bir test çalışması başarılı oldu ancak test üç kez tekrarlandığında her seferinde başarısızlık sonuçları alındı. Ağ hızı sürekli dalgalanır. Kod, tek bir anlık görüntü almış, kalıcı bir karar vermiş ve bağlantı bir an sonra değişse bile devam etmişti.

Çıkarım: Kalıcı bir eylemi, hareketli bir hedefin tek bir okumasına dayandırmayın. Bir kez sorgulamak (polling) yerine değişiklik olaylarına (change events) abone olun.

Ekibin uyguladığı pratik çözümler

  • Bağlantı değişikliklerine abone olun. navigator.connection değerini bir kez okumak yerine, kod artık change olayını dinliyor ve indirme sırasında bant genişliği düşerse veya artarsa buna tepki veriyor.
  • Bir "ilerleme yok" bekçisi (watchdog) ekleyin. Bir zamanlayıcı, kısa bir süre boyunca ilerleme kaydetmeyen tüm istekleri iptal ederek tarayıcının yeniden denemesine veya yedek plana geçmesine olanak tanır.
  • İndirme sırasında CDN değiştirmeyi bırakın. Yavaş bir bağlantıda büyük bir dosyanın kaynağını değiştirmek, aktarımı sıfırdan başlatarak halihazırda alınmış baytların boşa gitmesine neden olur. İndirme artık tüm süresi boyunca başlangıçta seçilen CDN'e bağlı kalıyor.
  • Ağır önbelleğe alma (caching) işlemlerini erteleyin. Önbelleğe büyük miktarda veri yazan görevler, runtime yüklemesini bitirene kadar ertelenerek kritik yolun kısa tutulması sağlanır.

Eğer panelleriniz rahatsız edici derecede düzenli bir tablo çiziyorsa, daha derine inin. Eğer bir ağ ölçümü hiç değişmiyorsa, onu bir yer tutucu olarak kabul edin. Ve eğer tek bir anlık görüntü, çok megabaytlık bir indirme işleminin kaderini belirliyorsa, bir seraba bahis oynuyorsunuz demektir. Bu bahisler, kullanıcı güvenini sarsan sessiz hatalar olarak karşınıza çıkar; ki bu, sonradan ne kadar zekice kod yazılırsa yazılsın tam olarak onarılamayacak bir durumdur.