براؤزر سورس اپ ڈیٹ کے بعد ایک ڈونیشن دو الرٹ کیوں پیدا کرتا ہے

ایک ڈونیشن دو الرٹ کیوں پیدا کرتا ہے

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

اپ ڈیٹ بذات خود لازمی طور پر خرابی کی وجہ نہیں ہوتا۔ یہ اکثر صرف کنکشن لاجک میں موجود غلطی کو ظاہر کرتا ہے۔ مثال کے طور پر، اِنیشلائزیشن فنکشن صفحہ لوڈ ہونے پر چل سکتا ہے، پھر کنکشن بحال ہونے پر اور ایک بار پھر سروس میسج ملنے کے بعد۔ ہر اجرا donation ایونٹ کی نئی سبسکرپشن شامل کرتا ہے۔

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

نقل کہاں پیدا ہو رہی ہے اسے کیسے تلاش کریں

ایک سادہ ٹیسٹ سے شروع کریں۔ براؤزر سورس کا لنک الگ ونڈو یا ٹیب میں کھولیں، صفحہ کی صرف ایک انسٹنس رکھیں اور ٹیسٹ ایونٹ بھیجیں۔ اگر الرٹ ایک بار ظاہر ہوتا ہے، تو وجہ غالباً سین کی ترتیبات یا سورس کی متعدد انسٹنسز سے متعلق ہے۔ اگر یہ الگ ٹیب میں ہی نقل ہو رہا ہے، تو صفحہ کا کوڈ اور سبسکرپشن میکانزم جانچیں۔

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

تشخیص کے لیے ہر ایونٹ کے ساتھ اس کا شناخت کنندہ شامل کریں، اگر یہ ڈونیشن ڈیٹا میں منتقل ہوتا ہو۔ یہ شناخت کنندہ وصولی کے وقت اور دکھانے سے پہلے ریکارڈ کریں۔ دو کالز میں ایک ہی شناخت کنندہ ظاہر کرتا ہے کہ ایک ہی ایونٹ دوبارہ پروسیس ہوا ہے۔ دو مختلف شناخت کنندگان دو ڈیلیوریوں کی نشاندہی کرتے ہیں جنہیں الگ سے جانچنا ہوگا۔

صرف ٹیبز کی تعداد نہ جانچیں۔ OBS میں دو انسٹنسز سین کاپی کرنے، نیسٹڈ سین شامل کرنے یا اسی ایڈریس کے ساتھ براؤزر سورس دوبارہ شامل کرنے کے بعد ظاہر ہو سکتی ہیں۔ بعض اوقات ایک سورس الگ لیئر میں رہتا ہے اور دوسرا اس کے اوپر شامل ہو جاتا ہے۔ بصری طور پر یہ ڈبل الرٹ لگتا ہے، حالانکہ ایونٹ ایک بار آیا تھا۔

دوبارہ کنکشن کے بعد دوبارہ سبسکرپشن

سب سے عام وجہ یہ ہے کہ ہینڈلر ہر کنکشن پر شامل ہوتا ہے لیکن منقطع ہونے پر ہٹایا نہیں جاتا۔ آسان الفاظ میں مسئلہ یوں ہے: فنکشن socket.on کو الرٹ دکھانے والے ہینڈلر کے ساتھ چلاتا ہے، پھر کنکشن منقطع ہوتا ہے، ایپلیکیشن دوبارہ جڑتی ہے اور socket.on دہراتی ہے۔ اس کے بعد ایک آنے والا ڈونیشن دو فنکشنز کو کال کرتا ہے۔ اگلی دوبارہ کنکشن پر وہ مزید بڑھ سکتے ہیں۔

یہی غلطی عام addEventListener کے ساتھ بھی ہوتی ہے۔ اگر اِنیشلائزیشن فنکشن کئی بار کال ہو، تو براؤزر ایک ہی ایونٹ کے کئی سننے والے شامل کر دیتا ہے۔ "اِنیشلائزیشن پہلے ہو چکی ہے" کے فلیگ کی جانچ ہمیشہ مدد نہیں کرتی: مکمل صفحہ ریفریش پر ویری ایبلز ری سیٹ ہو جاتے ہیں، اور اسی صفحہ کے اندر دوبارہ کنکشن پر مسئلہ برقرار رہتا ہے۔

سبسکرپشن کنکشن لائف سائیکل پر ایک بار بنانی چاہیے، اور نئی سے پہلے پرانی سبسکرپشن واضح طور پر ہٹانی چاہیے۔ ایونٹ ہینڈلرز کے لیے removeEventListener اور وہی فنکشن ریفرنس استعمال ہوتا ہے جو کنکشن کے وقت دیا گیا تھا۔ ساکٹ والی لائبریریوں کے لیے عام طور پر off، unsubscribe یا اسی طرح کا منقطع کرنے کا طریقہ درکار ہوتا ہے۔

ساکٹ کے لیے کم سے کم خاکہ یوں ہو سکتا ہے: const onDonation = data => showAlert(data); socket.off('donation', onDonation); socket.on('donation', onDonation); function cleanup() { socket.off('donation', onDonation); window.removeEventListener('beforeunload', cleanup); socket.close(); } window.addEventListener('beforeunload', cleanup);

یہاں اہم مخصوص لائبریری نہیں بلکہ اقدامات کی ترتیب ہے۔ ہینڈلر ویری ایبل میں محفوظ ہوتا ہے، اس لیے اسے اسی ریفرنس سے ہٹایا جا سکتا ہے۔ نئی سبسکرپشن سے پہلے پرانی ہٹائی جاتی ہے، اور صفحہ بند ہونے یا سورس رکنے پر cleanup چلتا ہے۔ اگر ہر اجرا پر نیا ساکٹ بنتا ہے، تو پہلے پرانا بند کریں اور پھر نیا بنائیں۔ ورنہ دونوں کنکشنز ایک ہی ڈیٹا وصول کرتے رہ سکتے ہیں۔

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

OBS اور براؤزر سورس میں کیا جانچیں

اگر الگ ونڈو الرٹ ایک بار دکھاتی ہے، تو سین کی طرف جائیں۔ پیش منظر روکیں، اضافی لیئرز عارضی طور پر ہٹائیں اور ایک براؤزر سورس رکھیں۔ پھر مطلوبہ سین پر رویہ جانچیں۔ ایسا ٹیسٹ تمام سینز اور فلٹرز کی بیک وقت جانچ سے تیز ہے۔

• ایک ہی صفحہ ایڈریس والے دو سورسز تلاش کریں۔
• سین کاپیوں اور نیسٹڈ سینز کی جانچ کریں جہاں وہی اوورلے موجود ہو سکتا ہے۔
• یقینی بنائیں کہ الرٹ بیک وقت براؤزر سورس اور اسی صفحہ والی کسی دوسری لیئر سے ظاہر نہیں ہو رہا۔
• ترتیبات بدلنے کے بعد سورس کو مکمل طور پر دوبارہ چلائیں، صرف سین تبدیل نہ کریں۔

بعض اوقات URL یا پیرامیٹرز اپ ڈیٹ ہونے کے بعد OBS میں براؤزر سورس کا پرانا ٹیب رہ جاتا ہے۔ سورس بند کر کے دوبارہ شامل کرنا مفروضے کی جانچ میں مدد کرتا ہے، لیکن یہ کوڈ کی درستی کا متبادل نہیں۔ اگر ہر اپ ڈیٹ کے بعد مسئلہ واپس آتا ہے، تو ہینڈلر کی دوبارہ رجسٹریشن یا ڈبل کنکشن تلاش کریں۔

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

ایک ایونٹ کی ڈپلیکیٹ ڈیلیوری سے بچاؤ

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

بہترین طریقہ ڈونیشن کا منفرد شناخت کنندہ جانچنا ہے۔ ایونٹ کو قطار میں لگانے سے پہلے اس کا شناخت کنندہ پہلے سے پروسیس شدہ ایونٹس کے سیٹ میں محفوظ کریں۔ اگر ایسا شناخت کنندہ پہلے آ چکا ہو، تو تکرار کو نظر انداز کریں۔ فہرست کو محدود وقت تک رکھیں تاکہ یہ بے حد نہ بڑھے۔

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

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

اگر ایونٹ کئی ٹیبز یا کمپونینٹس کے درمیان منتقل ہوتا ہے، تو جانچیں کہ کیا اسے بیک وقت کئی وصول کنندگان پروسیس نہیں کر رہے۔ ایک مشترکہ میسج چینل کئی ہینڈلرز سے منسلک ہو سکتا ہے۔ ایسی صورت میں یا تو ایک ہی صارف رکھیں، یا واضح طور پر طے کریں کہ کون سا کمپونینٹ الرٹ دکھانے کا ذمہ دار ہے۔

کیش صاف کرنا ہمیشہ مدد کیوں نہیں کرتا

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

جانچیں کہ واقعی فائلوں کا نیا ورژن لوڈ ہو رہا ہے۔ عارضی طور پر ریسورس کا ایڈریس تبدیل کریں یا فراہم کردہ اپ ڈیٹ میکانزم استعمال کریں، پھر براؤزر سورس دوبارہ چلائیں۔ اس کے بعد ایک ونڈو اور سورس کی ایک انسٹنس کے ساتھ دوبارہ ٹیسٹ کریں۔ لنک میں بے ترتیب پیرامیٹرز مستقل طور پر شامل نہ کریں: یہ کیش کے بہت سے ورژن بنا کر تشخیص کو پیچیدہ کر سکتا ہے۔

اگر درمیانی کیش یا service worker استعمال ہو رہا ہے، تو وہ بھی پرانا اسکرپٹ دے سکتا ہے۔ ایسی صورت میں لوڈ شدہ فائل کے ورژن کا اس ورژن سے موازنہ کریں جس کی آپ توقع کرتے ہیں۔ لیکن پرانی فائل کی صورت میں بھی دوبارہ سبسکرپشن کی وجہ دور کرنی ہوگی، ورنہ اگلی اپ ڈیٹ کے بعد مسئلہ پھر ظاہر ہوگا۔

الرٹ کے کوڈ میں کیا جانچیں

پہلے وہ تمام مقامات تلاش کریں جہاں socket.on، addEventListener، کنکشن فنکشنز اور قطار کا آغاز کال ہوتے ہیں۔ بعض اوقات مسئلہ ایک ہینڈلر میں نہیں بلکہ یہ ہوتا ہے کہ دو مختلف ماڈیولز آزادانہ طور پر donation ایونٹ سنتے ہیں اور ہر ایک اپنا ڈسپلے چلاتا ہے۔

پھر کمپونینٹ لائف سائیکل جانچیں، اگر الرٹ کسی فریم ورک کے ذریعے ظاہر ہوتا ہے۔ سبسکرپشن کو ایفیکٹ یا اسی طرح کے بلاک میں رکھیں اور صفائی کا فنکشن واپس کریں۔ پچھلا ہٹائے بغیر ہر اسٹیٹ اپ ڈیٹ پر نیا ہینڈلر نہیں بنایا جا سکتا۔ عام JavaScript میں فعال ساکٹ اور موجودہ ہینڈلر کا ریفرنس محفوظ رکھنا ضروری ہے تاکہ صفحہ رکنے پر انہیں درست طریقے سے بند کیا جا سکے۔

دوبارہ کنکشن کے ٹائمرز جانچیں۔ نیا ٹائمر پرانے کے اوپر نہیں چلنا چاہیے۔ ورنہ کئی منقطعی کے بعد متوازی کنکشن کی کوششیں بنتی ہیں اور ان کے ساتھ اضافی سبسکرپشنز بھی۔ ہر ٹائمر کے لیے clearTimeout یا clearInterval کے ذریعے صفائی درکار ہے اگر اس کی مزید ضرورت نہ ہو۔

الگ سے وہ کوڈ دیکھیں جو الرٹ دکھاتا ہے۔ اسے بیک وقت عنصر کو قطار میں ڈالنا اور اسی آبجیکٹ کے لیے فوراً ڈسپلے فنکشن کال کرنا نہیں چاہیے۔ یہ بھی جانچیں کہ عنصر کی اسٹیٹ بدلنے پر اینیمیشن دوبارہ نہیں چلتی۔ اگر لاگ میں ایک وصولی اور قطار میں ایک اندراج ہے، لیکن اسکرین پر دو اطلاعات ہیں، تو تلاش یہیں کرنی ہے۔

تشخیصی چیک لسٹ: ترتیب سے کیا کریں

1. براؤزر سورس کا URL الگ ٹیب میں کھولیں اور ایک ٹیسٹ ڈونیشن بھیجیں۔ ریکارڈ کریں کہ OBS سے باہر تکرار ظاہر ہوتی ہے یا نہیں۔
2. سین میں سورس کی صرف ایک انسٹنس رکھیں۔ سین کاپیوں، نیسٹڈ سینز اور لیئرز کی جانچ کریں جہاں وہی ایڈریس موجود ہو سکتا ہے۔
3. وصولی، قطار میں لگانے اور دکھانے کے مراحل پر ایونٹ شناخت کنندہ کے ساتھ لاگ شامل کریں۔ اس سے نظر آئے گا کہ آبجیکٹس کی تعداد کہاں بڑھتی ہے۔
4. socket.on اور addEventListener کی تمام کالز تلاش کریں۔ جانچیں کہ پرانے ہینڈلرز socket.off اور removeEventListener کے ذریعے اسی فنکشن ریفرنس کے ساتھ ہٹائے جاتے ہیں یا نہیں۔
5. دوبارہ کنکشن جانچیں: پرانا ساکٹ بند ہوتا ہے، پرانا ٹائمر منسوخ ہوتا ہے اور پچھلی کے اوپر نئی سبسکرپشن نہیں بنتی۔
6. قطار سے پہلے ڈونیشن کے منفرد شناخت کنندہ کی جانچ شامل کریں، پھر سورس مکمل طور پر دوبارہ چلائیں اور ایک ایونٹ کے ساتھ ٹیسٹ دہرائیں۔

اگر الگ ٹیب ایونٹ ایک بار وصول کرتا ہے لیکن OBS دو الرٹ دکھاتا ہے، تو سورس کی دوسری انسٹنس یا سینز میں نقل تلاش کریں۔ اگر ایونٹ الگ ٹیب میں ہی دو بار آتا ہے، تو سبسکرپشنز، کنکشنز اور سرور ڈیلیوری جانچیں۔ اگر وصولی اور قطار ایک بار ریکارڈ ہوتی ہیں لیکن اسکرین پر دو اطلاعات ہیں، تو مسئلہ بصری پرت میں ہے۔