५.५ MB रनटाइम असलेला एक ब्राउझर-आधारित पायथन प्लेग्राउंड (Python playground) संथ कनेक्शन असलेल्या वापरकर्त्यांसाठी शांतपणे निकामी (failing silently) होऊ लागला. याचे कारण चुकीच्या पद्धतीने वापरलेले Network Information API आणि समस्येचे चुकीचे वर्गीकरण करणारे एरर-ग्रुपिंग डॅशबोर्ड होते. हा बग अनेक आठवडे लपून राहिला, ज्यामुळे डेव्हलपर्सचा वेळ वाया गेला आणि वापरकर्त्यांचा एक मोठा वर्ग कोड रन करण्यास असमर्थ ठरला.

समस्या कशी समोर आली

प्लेग्राउंडच्या एरर ट्रॅकरवर एक लक्षवेधी संदेश फ्लॅश झाला: “undefined is not an object.” या शीर्षकावरून तो एक साधा JavaScript टायपो असावा असे वाटले, त्यामुळे टीम एका अस्तित्वात नसलेल्या कोड पाथचा (code path) शोध घेऊ लागली. जेव्हा त्यांनी रॉ मेटाडेटा (raw metadata) तपासला, तेव्हा त्यांना दिसले की ८९% घटना प्रत्यक्षात नेटवर्क टाइमआउट होत्या. डॅशबोर्डने आलेली पहिली एरर घेतली आणि संपूर्ण बॅचला तेच नाव दिले, ज्यामुळे मूळ त्रुटीचा प्रकार लपला गेला.

धडा १ – डॅशबोर्डची शीर्षके दिशाभूल करणारी असू शकतात

जो डॅशबोर्ड घटना एकत्रित (aggregate) करतो, तो तेव्हाच उपयुक्त ठरतो जेव्हा त्याचे ॲग्रिगेशन लॉजिक प्रत्येक घटनेच्या वास्तविक कारणाशी सुसंगत असते. येथे, एररच्या कारणाऐवजी लोकेशननुसार ग्रुपिंग केल्यामुळे क्लायंट-साइड बगचे चुकीचे चित्र समोर आले. मुख्य शिकवण: केवळ डॅशबोर्डच्या हेडलाईनवर आधारित समस्या दुरुस्त करू नका. संसाधने (resources) खर्च करण्यापूर्वी मूळ घटनांचा नमुना (sample) घ्या आणि प्रत्यक्षात काय घडत आहे याची पडताळणी करा.

धडा २ – प्लेसहोल्डर व्हॅल्यूज म्हणजे मोजमाप नव्हे

संथ कनेक्शन असलेल्या वापरकर्त्यांसाठी जड रनटाइम लोड करणे टाळण्यासाठी, कोडने Network Information API चा सल्ला घेतला आणि downlink प्रॉपर्टी वाचली, जी मेगाबिट्स प्रति सेकंद (megabits per second) रिपोर्ट करते. पहिल्या भेटीवर, Chrome अनेकदा वास्तविक मोजमापाऐवजी प्लेसहोल्डर परत करते. लॉजिकने त्या प्लेसहोल्डरला वेगवान कनेक्शन मानले आणि ऑप्टिमायझेशन वगळले, ज्यामुळे प्रत्यक्षात ज्या वापरकर्त्यांना मदत करायची होती, त्यांनाच अडथळा निर्माण झाला.

कोणत्याही डिफॉल्ट किंवा सेंटिनल (sentinel) व्हॅल्यूला "डेटा नाही" (no data) असे समजा. प्लेसहोल्डरमुळे फॉलबॅक स्ट्रॅटेजी (fallback strategy) कार्यान्वित झाली पाहिजे, त्याचा अर्थ वास्तविक वेग असा घेऊ नका.

धडा ३ – नेटवर्कची स्थिती बदलत असते, त्यामुळे एकच स्नॅपशॉट अविश्वसनीय असतो

downlink च्या समस्येनंतर, टीमने effectiveType तपासण्याकडे वळले, जे कनेक्शनचे “4g”, “3g” इत्यादींमध्ये वर्गीकरण करते. लॅबमधील एक चाचणी यशस्वी झाली, पण काही क्षणानंतर तीच चाचणी पुन्हा घेतल्यावर अयशस्वी ठरली. मोबाईल कनेक्शनमध्ये चढ-उतार होतात; वापरकर्ता एका सेकंदात वेगवान 4G लिंकवर असू शकतो आणि पुढच्याच सेकंदात संथ 3G वर जाऊ शकतो. केवळ पेज लोड होताना कनेक्शन तपासणे हा एक जुगार आहे.

योग्य दृष्टिकोन म्हणजे Network Information ऑब्जेक्टवरील change इव्हेंटला सबस्क्राईब करणे आणि एकदाच निर्णय घेण्याऐवजी बँडविड्थमधील कोणत्याही बदलाला प्रतिसाद देणे.

टीमने काय बदलले

  • दोन-टप्प्यातील डाउनलोड (Two-stage download) – रनटाइम आता एका लहान बूटस्ट्रॅप (bootstrap) फाईलने सुरू होतो. जर कनेक्शन संथ असल्याचे आढळले, तर बूटस्ट्रॅप उर्वरित रनटाइम लहान तुकड्यांमध्ये (chunks) मिळवतो, ज्यामुळे डाउनलोड पूर्णपणे थांबण्याची शक्यता कमी होते.
  • लाईव्ह मॉनिटरिंग (Live monitoring) – केवळ एकदाच downlink वाचण्याऐवजी, कोड आता change इव्हेंटवर लक्ष ठेवतो आणि गरजेनुसार डाउनलोड स्ट्रॅटेजी बदलतो.
  • स्थिर सोर्स निवड (Stable source selection) – यापूर्वी, जेव्हा एखादा वेगवान एंडपॉइंट उपलब्ध व्हायचा, तेव्हा सिस्टम डाउनलोड दरम्यानच CDN बदलत असे. संथ लिंकवर यामुळे डाउनलोड शून्यापासून पुन्हा सुरू व्हायचे, ज्यामुळे समस्या अधिकच वाढायची. नवीन लॉजिक डाउनलोड पूर्ण होईपर्यंत सोर्स लॉक करते.
  • विलंबित कॅश राइट्स (Deferred cache writes) – ॲप वापरण्यायोग्य होण्यापूर्वी चालणाऱ्या जड कॅश ऑपरेशन्स आता रनटाइम सुरू झाल्यानंतरपर्यंत पुढे ढकलण्यात आले आहेत, ज्यामुळे महत्त्वाच्या डाउनलोडसाठी बँडविड्थ मोकळी होते.

व्यापक परिणाम

वेब-आधारित टूल्स बनवणाऱ्या डेव्हलपर्ससाठी, नेटवर्कमधील बदलशीलता (network variability) हा एक महत्त्वाचा घटक आहे. संथ लिंकवर होणारी शांत त्रुटी (silent failure) वापरकर्त्यांना निराश करते आणि टेलिमेट्री (telemetry) डेटा चुकीचा ठरवते, ज्यामुळे टीम चुकीच्या डिबगिंग मार्गावर जाते. या प्रकरणात, डेटाचा चुकीचा अर्थ लावल्यामुळे आठवडे निष्फळ तपासणी करण्यात गेली.

पुढे काय पाहावे

निष्कर्ष: जेव्हा डेटा खूपच अचूक किंवा स्वच्छ दिसतो, तेव्हा तो बहुधा प्लेसहोल्डर असतो; जेव्हा डॅशबोर्डची हेडलाईन एकाच बगकडे निर्देश करते, तेव्हा अधिक खोलवर तपासणी करा; आणि जेव्हा तुम्ही एकावेळच्या नेटवर्क रीडिंगवर निर्णय घेता, तेव्हा तुम्ही एका बदलत्या लक्ष्यावर (moving target) अवलंबून असता. या वास्तवांचा विचार केल्यास शांत त्रुटींचे रूपांतर अंदाजित आणि सुधारण्यायोग्य घटनांमध्ये होऊ शकते.