براؤزر پر مبنی ایک Python playground، جو 5.5 MB کا runtime فراہم کرتا ہے، سست کنکشنز والے صارفین کے لیے خاموشی سے ناکام ہونے لگا۔ اس کی اصل وجہ Network Information API کا غلط استعمال اور ایک ایرر گروپنگ ڈیش بورڈ تھا جس نے مسئلے کو غلط لیبل لگا دیا تھا۔ یہ بگ ہفتوں تک چھپا رہا، ڈویلپرز کا وقت ضائع کیا، اور صارفین کے ایک حصے کو کوڈ چلانے سے روک دیا۔

مسئلہ کیسے سامنے آیا

پلے گراؤنڈ کے ایرر ٹریکر نے ایک واحد، توجہ طلب پیغام دکھایا: “undefined is not an object.” اس عنوان سے ایسا لگا جیسے یہ JavaScript کی کوئی سادہ سی ٹائپو (typo) غلطی ہے، چنانچہ ٹیم نے ایک غیر موجود کوڈ پاتھ کا پیچھا کرنا شروع کر دیا۔ جب انہوں نے خام میٹا ڈیٹا (raw metadata) کا معائنہ کیا، تو انہوں نے دیکھا کہ 89% واقعات درحقیقت نیٹ ورک ٹائم آؤٹ (network timeouts) تھے۔ ڈیش بورڈ نے آنے والے پہلے ایرر کو لیا اور اسے پورے بیچ (batch) کا نام دے دیا، جس سے اصل ناکامی کی قسم چھپ گئی۔

سبق نمبر 1 – ڈیش بورڈ کے عنوانات گمراہ کن ہو سکتے ہیں

ایسا ڈیش بورڈ جو واقعات کو یکجا (aggregate) کرتا ہے، صرف اسی صورت میں مددگار ہوتا ہے اگر اس کی ایکریگیشن لاجک ہر واقعے کی اصل وجہ کی عکاسی کرے۔ یہاں، ایرر کی وجہ کے بجائے لوکیشن کے لحاظ سے گروپنگ کرنے سے کلائنٹ سائیڈ بگ کی ایک غلط تصویر پیش ہوئی۔ حاصلِ کلام یہ ہے کہ: کبھی بھی صرف ڈیش بورڈ کی ہیڈ لائن کی بنیاد پر مسئلہ حل کرنے کی کوشش نہ کریں۔ وسائل مختص کرنے سے پہلے بنیادی واقعات کا ایک نمونہ لیں اور تصدیق کریں کہ اصل میں کیا ہو رہا ہے۔

سبق نمبر 2 – پلیس ہولڈر ویلیوز پیمائش نہیں ہیں

سست رفتار لنکس والے صارفین کے لیے بھاری بھرکم runtime لوڈ کرنے سے بچنے کے لیے، کوڈ نے Network Information API سے رجوع کیا اور downlink پراپرٹی کو پڑھا، جو میگا بٹ فی سیکنڈ میں رپورٹ کرتی ہے۔ پہلی بار وزٹ کرنے پر، Chrome اکثر اصل پیمائش کے بجائے ایک پلیس ہولڈر (placeholder) واپس کرتا ہے۔ لاجک نے اس پلیس ہولڈر کو تیز کنکشن سمجھا اور آپٹیمائزیشن کو چھوڑ دیا، جس کے نتیجے میں مؤثر طریقے سے انہی صارفین کو بلاک کر دیا گیا جن کی مدد کے لیے اسے بنایا گیا تھا۔

کسی بھی ڈیفالٹ یا سینٹینل ویلیو کو "کوئی ڈیٹا نہیں" (no data) کے طور پر لیں۔ ایک پلیس ہولڈر کو فال بیک حکمت عملی (fallback strategy) شروع کرنی چاہیے، اسے اصل اسپیڈ کی پیمائش نہیں سمجھنا چاہیے۔

سبق نمبر 3 – نیٹ ورک کے حالات بدلتے رہتے ہیں، اس لیے ایک ہی اسنیپ شاٹ قابل اعتماد نہیں ہے

downlink کے مسئلے کے بعد، ٹیم نے effectiveType کو چیک کرنے کا طریقہ اپنایا، جو کنکشنز کو “4g”، “3g” وغیرہ میں درجہ بندی کرتا ہے۔ ایک فوری لیب ٹیسٹ کامیاب رہا، لیکن وہی ٹیسٹ کچھ ہی لمحوں بعد دوبارہ کرنے پر ناکام ہو گیا۔ موبائل کنکشنز میں اتار چڑھاؤ آتا رہتا ہے؛ ایک صارف ایک سیکنڈ میں تیز 4G لنک پر نظر آ سکتا ہے اور اگلے ہی سیکنڈ سست 3G پر گر سکتا ہے۔ صرف پیج لوڈ کے وقت کنکشن چیک کرنا ایک جوا کھیلنے کے مترادف ہے۔

درست طریقہ یہ ہے کہ Network Information آبجیکٹ پر change ایونٹ کو سبسکرائب کیا جائے اور ایک بار کے فیصلے کے بجائے بینڈوتھ میں کسی بھی تبدیلی پر ردعمل دیا جائے۔

ٹیم نے کیا تبدیلیاں کیں

  • دو مرحلہ وار ڈاؤن لوڈ – اب runtime ایک چھوٹی سی بوٹ اسٹریپ (bootstrap) فائل سے شروع ہوتا ہے۔ اگر کنکشن سست پایا جاتا ہے، تو بوٹ اسٹریپ باقی runtime کو چھوٹے ٹکڑوں (chunks) میں ڈاؤن لوڈ کرتا ہے، جس سے مکمل ڈاؤن لوڈ رک جانے کا امکان کم ہو جاتا ہے۔
  • لائیو مانیٹرنگ – صرف ایک بار downlink پڑھنے کے بجائے، کوڈ اب change ایونٹس کو سنتا ہے اور ضرورت کے مطابق ڈاؤن لوڈ کی حکمت عملی کو فوری طور پر تبدیل کرتا ہے۔
  • مستحکم ذریعے کا انتخاب – پہلے سسٹم ڈاؤن لوڈ کے دوران CDNs تبدیل کر دیتا تھا جب کوئی تیز تر اینڈ پوائنٹ نظر آتا۔ سست لنک پر اس سے ڈاؤن لوڈ دوبارہ صفر سے شروع ہو جاتا تھا، جس سے مسئلہ مزید سنگین ہو جاتا تھا۔ نیا لاجک ڈاؤن لوڈ کے دوران ذریعے (source) کو لاک کر دیتا ہے۔
  • تاخیری کیش رائٹس (Deferred cache writes) – بھاری کیش آپریشنز جو ایپ کے استعمال کے قابل ہونے سے پہلے چلتے تھے، اب runtime شروع ہونے کے بعد تک ملتوی کر دیے گئے ہیں، تاکہ اہم ڈاؤن لوڈ کے لیے بینڈوتھ خالی رہے۔

وسیع تر اثرات

ویب پر مبنی ٹولز بنانے والے ڈویلپرز کے لیے، نیٹ ورک کے اتار چڑھاؤ کا معاملہ انتہائی اہمیت کا حامل ہے۔ سست لنک پر خاموش ناکامی صارفین کو مایوس کرتی ہے اور ٹیلی میٹری (telemetry) کو غلط رخ پر لے جاتی ہے، جس سے ٹیمیں غلط ڈی بگنگ کے راستے پر نکل جاتی ہیں۔ اس معاملے میں، ڈیٹا کی غلط تشریح نے ہفتوں کی بے سود تحقیقات کا باعث بنا۔

آگے کیا نظر رکھنا ہے

حاصلِ کلام: جب ڈیٹا بہت زیادہ صاف ستھرا نظر آئے، تو غالباً وہ ایک پلیس ہولڈر ہے؛ جب ڈیش بورڈ کی ہیڈ لائن کسی ایک بگ کی طرف اشارہ کرے، تو مزید گہرائی میں جائیں؛ اور جب آپ ایک بار کے نیٹ ورک ریڈ پر فیصلہ کرتے ہیں، تو آپ ایک متحرک ہدف پر شرط لگا رہے ہوتے ہیں۔ ان حقائق کے مطابق خود کو ڈھالنا خاموش ناکامیوں کو قابلِ پیش گوئی اور قابلِ بحالی واقعات میں بدل دیتا ہے۔