براؤزرز تک 5.5 MB کا Python runtime پہنچانے والی ایک ٹیم نے دریافت کیا کہ حالیہ sprint کے دوران لاگ کیے گئے 69% ایررز ایک ہی گمراہ کن عنوان کے تحت آئے، اور ان میں سے 89% درحقیقت نیٹ ورک ٹائم آؤٹ (network timeouts) تھے۔ غلط رپورٹنگ نے ڈویلپرز کو غلط ڈیبگنگ (debugging) کے راستے پر ڈال دیا اور صارفین کے ایک بڑے حصے کو خاموش ڈاؤن لوڈ کی ناکامیوں (silent download failures) کا سامنا کرنا پڑا—یہ ایک ایسا مسئلہ ہے جسے بڑے اثاثے (assets) یکجا کرنے والا کوئی بھی ویب ایپ جلد ہی دہرا سکتی ہے۔

ڈیش بورڈ نے گمراہ کیا

ایرر ٹریکنگ سسٹم خود بخود واقعات کو اس کوڈ کی جگہ کے مطابق گروپ کرتا ہے جہاں وہ پہلی بار ظاہر ہوتے ہیں۔ نتیجے کے طور پر جو عنوان سامنے آیا وہ runtime loader میں ایک سادہ سی خرابی (bug) معلوم ہوا، اس لیے پوری sprint ان کوڈ پاتھز (code paths) کی تلاش میں گزر گئی جنہوں نے کبھی ٹائم آؤٹ نہیں کیا تھا۔ جب ٹیم نے بنیادی میٹا ڈیٹا (metadata) کا جائزہ لیا، تو اصل تصویر سامنے آئی: زیادہ تر ناکامیاں کوئی بگ (bug) نہیں تھیں بلکہ رکی ہوئی نیٹ ورک کنکشنز تھیں جنہوں نے ٹائم آؤٹ کو ٹرگر کیا تھا۔

نتیجہ: ایرر کا عنوان محض سہولت کے لیے ہوتا ہے، تشخیص کے لیے نہیں۔ وقتاً فوقتاً اصل ڈیٹا کی گہرائی میں جائیں تاکہ تصدیق ہو سکے کہ ہیڈ لائن حقیقت میں کس چیز کی نمائندگی کر رہی ہے۔

براؤزر کنکشن API نے ایک پلیس ہولڈر فراہم کیا

سست رفتار صارفین کو 5.5 MB کے ڈاؤن لوڈ میں الجھانے سے بچنے کے لیے، ڈویلپرز نے براؤزر کی Network Information API (navigator.connection) سے مشورہ لیا۔ API نے ہر پہلی بار آنے والے وزیٹر کے لیے مستقل 1.7 Mbps بینڈوتھ (bandwidth) رپورٹ کی۔

براؤزرز تب ڈیفالٹ ویلیو (default value) دیتے ہیں جب ان کے پاس نئے صارف کے لیے کوئی تاریخی ڈیٹا نہ ہو۔ وہ ڈیفالٹ ایک اشارہ ہے، حتمی رفتار نہیں۔ جب ہر نئے سیشن کے لیے وہی پلیس ہولڈر نظر آئے، تو یہ اس بات کا اشارہ ہے کہ API ابھی اس سامعین (audience) کے لیے درست طریقے سے کیلیبریٹ (calibrate) نہیں ہوئی ہے۔

نتیجہ: کسی بھی ایسے نیٹ ورک سگنل کو جو کبھی تبدیل نہ ہو، اسے ایک متبادل (fallback) کے طور پر لیں، نہ کہ حتمی پیمانے (metric) کے طور پر۔

یک بار کے اسنیپ شاٹس (snapshots) ناقابل اعتبار ہیں

ناقابل اعتبار بینڈوتھ ہنٹ کو مسترد کرنے کے بعد، ٹیم نے ایک مختلف سگنل کا استعمال کیا جو ان کے ٹیسٹ سویٹ (test suite) میں کام کرتا ہوا محسوس ہوا۔ ایک ٹیسٹ رن کامیاب رہا، لیکن ٹیسٹ کو تین بار دہرانے پر ہر بار ناکامی ہوئی۔ نیٹ ورک کی رفتار مسلسل تبدیل ہوتی رہتی ہے۔ کوڈ نے ایک ہی اسنیپ شاٹ لیا، ایک مستقل فیصلہ کیا، اور پھر آگے بڑھ گیا چاہے ایک لمحے بعد کنکشن تبدیل ہو گیا ہو۔

نتیجہ: کسی بدلتے ہوئے ہدف کی ایک ہی ریڈنگ پر مستقل عمل کی بنیاد نہ رکھیں۔ ایک بار پولنگ (polling) کرنے کے بجائے تبدیلی کے واقعات (change events) کو سبسکرائب کریں۔

عملی اصلاحات جو ٹیم نے نافذ کیں

  • کنکشن کی تبدیلیوں کو سبسکرائب کریں۔ navigator.connection کو صرف ایک بار پڑھنے کے بجائے، اب کوڈ change ایونٹ کو سنتا ہے اور اگر ڈاؤن لوڈ کے دوران بینڈوتھ کم یا زیادہ ہو جائے تو اس پر ردعمل دیتا ہے۔
  • ایک "no-progress" واچ ڈاگ (watchdog) شامل کریں۔ ایک ٹائمر کسی بھی ایسی درخواست کو منسوخ کر دیتا ہے جو مختصر وقفے کے بعد کوئی پیش رفت نہ کرے، جس سے براؤزر کو دوبارہ کوشش کرنے یا متبادل استعمال کرنے کا موقع ملتا ہے۔
  • ڈاؤن لوڈ کے دوران CDNs کو تبدیل کرنا بند کریں۔ سست لنک پر بڑی فائل کے ذریعے (source) کو تبدیل کرنے سے ٹرانسفر صفر سے دوبارہ شروع ہو جاتا ہے، جس سے پہلے سے موصول شدہ بائٹس ضائع ہو جاتے ہیں۔ اب ڈاؤن لوڈ اپنی پوری مدت کے لیے شروع میں منتخب کردہ CDN پر ہی قائم رہتا ہے۔
  • بھاری کیشنگ (caching) کے کاموں کو ملتوی کریں۔ وہ ٹاسک جو کیش میں بڑی مقدار میں ڈیٹا لکھتے ہیں، انہیں رن ٹائم لوڈ مکمل ہونے تک ملتوی کر دیا جاتا ہے، تاکہ اہم راستہ (critical path) مختصر رہے۔

اگر آپ کے ڈیش بورڈز غیر معمولی طور پر صاف ستھری تصویر پیش کرتے ہیں، تو مزید گہرائی میں جائیں۔ اگر نیٹ ورک کی پیمائش کبھی تبدیل نہ ہو، تو اسے ایک پلیس ہولڈر سمجھیں۔ اور اگر ایک ہی اسنیپ شاٹ کئی میگا بائٹ کے ڈاؤن لوڈ کا فیصلہ کرتا ہے، تو آپ ایک سراب پر جوا لگا رہے ہیں۔ یہ جوئے خاموش ناکامیوں کی صورت میں سامنے آتے ہیں جو صارفین کے اعتماد کو کم کر دیتے ہیں—ایسی چیز جسے بعد میں کتنا ہی ذہین کوڈ کیوں نہ ہو، مکمل طور پر ٹھیک نہیں کر سکتا۔