बग्गी सर्विस वर्कर को हटाया जा रहा है

कभी-कभी बग्गी के सर्विस वर्कर को डिप्लॉय किया जाता है, और फिर समस्याओं का सामना करना पड़ता है. उदाहरण के लिए, किसी सर्विस वर्कर को रजिस्ट्रेशन के समय पार्स किया जा सकता है और वह इंस्टॉल हो जाता है. हालांकि, fetch इवेंट में गड़बड़ी वाले कोड की वजह से, हो सकता है कि वह अनुरोधों का जवाब न दे. इस वजह से, यह खाली पेज बन सकता है. एक और संभावना यह है कि पेज मार्कअप को कैश मेमोरी में सेव किया जाता है. साथ ही, सर्विस वर्कर सिर्फ़ अगली विज़िट के लिए Cache इंस्टेंस से पुराने मार्कअप रिस्पॉन्स दिखाता है.

ऐसे कई तरीके हैं, जिनसे सर्विस वर्कर बैकफ़ायर कर सकते हैं और प्रोडक्शन वेबसाइट पर यह एक डरावनी समस्या है. फिर भी, सभी चीज़ें गुम नहीं होती हैं. इस समस्या को ठीक करने और काम पर वापस आने के कई तरीके हैं.

नो-ऑप सर्विस वर्कर को डिप्लॉय करना

किसी गड़बड़ी सर्विस वर्कर से निपटने के लिए, आम तौर पर एक बेसिक no-op सर्विस वर्कर को डिप्लॉय करना होता है, जो fetch इवेंट हैंडलर के बिना तुरंत इंस्टॉल और चालू हो जाता है:

// sw.js

self.addEventListener('install', () => {
  // Skip over the "waiting" lifecycle state, to ensure that our
  // new service worker is activated immediately, even if there's
  // another tab open controlled by our older service worker code.
  self.skipWaiting();
});

self.addEventListener('activate', () => {
  // Optional: Get a list of all the current open windows/tabs under
  // our service worker's control, and force them to reload.
  // This can "unbreak" any open windows/tabs as soon as the new
  // service worker activates, rather than users having to manually reload.
  self.clients.matchAll({
    type: 'window'
  }).then(windowClients => {
    windowClients.forEach((windowClient) => {
      windowClient.navigate(windowClient.url);
    });
  });
});

चेतावनी: सलाह: बिना किसी काम वाले सर्विस वर्कर को डिप्लॉय करते समय, पक्का करें कि सर्विस वर्कर यूआरएल में कोई बदलाव न हो! ऐसा न होने पर, गड़बड़ी वाले सर्विस वर्कर के साथ नो-ऑप सर्विस वर्कर चालू रहेगा और समस्याएं बनी रहेंगी.

यह सर्विस वर्कर, install इवेंट में self.skipWaiting() पर कॉल करने पर, तुरंत इंस्टॉल और चालू हो जाएगा. इसके अलावा, activate इवेंट में अतिरिक्त कोड को WindowClient के साथ खुले हुए ऐसे किसी भी टैब को ज़बरदस्ती फिर से लोड किया जा सकता है जिसे सर्विस वर्कर कंट्रोल करता है.

यह बहुत ज़रूरी है कि नो-ऑप सर्विस वर्कर में कोई fetch इवेंट हैंडलर शामिल न हो. जब कोई सर्विस वर्कर, अनुरोधों को हैंडल नहीं करता है, तो वे अनुरोध ब्राउज़र में इस तरह पास हो जाते हैं, जैसे कोई सर्विस वर्कर मौजूद न हो. नो-ऑप सर्विस वर्कर को डिप्लॉय करने पर, गड़बड़ी वाले सर्विस वर्कर को ठीक किया जा सकता है और बाद में अपडेट के तौर पर डिप्लॉय किया जा सकता है.

यह तरीका कुछ हद तक काम करता है, क्योंकि ब्राउज़र सेवा वर्कर को एचटीटीपी कैश मेमोरी में रखने के लिए मज़बूत सुरक्षा उपाय करते हैं. साथ ही, वे अपडेट के लिए सर्विस वर्कर की सामग्री की बाइट-टू-बाइट जांच करते हैं. ये डिफ़ॉल्ट समस्या को जल्दी से ठीक करने के लिए किसी बग्गी सर्विस वर्कर के लिए नो-ऑप रिप्लेसमेंट को डिप्लॉय करना संभव बनाते हैं.

ध्यान दें: आपके सर्विस वर्कर के रोल आउट के तौर पर, नो-ऑप सर्विस वर्कर को हाथ में रखना बेहतर होता है, जिसे ज़रूरत पड़ने पर बदला जा सकता है. पहले से प्लान बनाना और यह पक्का करना कि आपकी टीम के सभी लोगों को बिना किसी काम वाले सर्विस वर्कर के डिप्लॉयमेंट को मैनेज करने का तरीका पता है. इससे, डिप्लॉयमेंट के बाद उनमें होने वाली देरी से बचा जा सकता है.

ये अतिरिक्त कदम उठाएं

बिना किसी काम के सर्विस वर्कर को डिप्लॉय करना, गाड़ी को न्यूट्रलाइज़ करने के लिए काफ़ी होना चाहिए. हालांकि, ज़रूरत पड़ने पर अतिरिक्त उपाय किए जा सकते हैं.

अगर आपको पुराने सर्विस वर्कर का यूआरएल नहीं पता है, तो क्या होगा?

कभी-कभी पहले से इंस्टॉल किए गए सर्विस वर्कर का यूआरएल अज्ञात होता है. ऐसा इसलिए हो सकता है, क्योंकि इसका वर्शन वर्शन है (उदाहरण के लिए, इसके फ़ाइल नाम में हैश शामिल है). इस मामले में, नो-ऑप सर्विस वर्कर को डिप्लॉय करना एक चुनौती हो सकती है, जो रजिस्टर किए गए हर पुराने सर्विस वर्कर के यूआरएल से मेल खाता हो. यह सबसे सही तरीकों के ख़िलाफ़ है, क्योंकि डेवलपर को शायद डिप्लॉय किए गए हर सर्विस वर्कर वर्शन के लिए, हर हैश याद नहीं होगा.

अच्छी बात यह है कि एक सर्विस वर्कर स्क्रिप्ट के अनुरोध के साथ, एक काम का एचटीटीपी अनुरोध हेडर भेजा जाता है: Service-Worker. वेब सर्वर पर इस हेडर की जांच करें और नो-ऑप सर्विस वर्कर को सेवा देने के लिए अनुरोध को रोकें. इस काम को पूरा करना, इस्तेमाल किए गए वेब सर्वर और बैकएंड स्टैक पर निर्भर करता है. इसलिए, इसे पूरा करने का तरीका जानने के लिए, संबंधित भाषा के दस्तावेज़ देखें.

आने वाले समय में सर्विस वर्कर के डिप्लॉयमेंट की स्थिति में, ऐसे ऐसेट नाम ही इस्तेमाल करें जो बदले नहीं हैं (उदाहरण के लिए, sw.js). इससे बाद में चीज़ें काफ़ी मुश्किल हो जाएंगी.

Clear-Site-Data हेडर सेट करें

अगर 'storage' वैल्यू वाला Clear-Site-Data रिस्पॉन्स हेडर सेट किया गया है, तो कुछ ब्राउज़र ऑरिजिन के लिए सभी सर्विस वर्कर का रजिस्ट्रेशन रद्द कर देंगे. हालांकि, इस तरीके को लेकर आपको कुछ चीज़ों के बारे में जानकारी होनी चाहिए:

• ध्यान रखें कि ऐसा करने पर, इससे जुड़े ऑरिजिन का पूरा स्टोरेज खाली हो जाएगा. इसमें localStorage, IndexedDB, sessionStorage, और अन्य स्टोरेज शामिल है. हालांकि, इसमें ऑरिजिन का एचटीटीपी कैश मेमोरी शामिल नहीं है.
• यह हेडर सभी ब्राउज़र पर काम नहीं करता.

इस हेडर को पूरा नहीं किया जा सकता, इसलिए इस समस्या को ठीक करने के लिए अकेले पर भरोसा नहीं किया जा सकता. इसलिए, नो-ऑप सर्विस वर्कर को डिप्लॉय करने के साथ-साथ, Clear-Site-Data को एक उपाय के तौर पर देखना सबसे सही तरीका होता है.

नुकसान हमेशा के लिए नहीं होता है

यह बहुत ही परेशान करने वाला हो सकता है कि जब गड़बड़ी करने वाले सर्विस वर्कर, खास तौर पर बड़ी और लोकप्रिय वेबसाइटों के लिए, उपयोगकर्ता अनुभव में रुकावट डालते हैं, लेकिन यह नुकसान कुछ समय के लिए होता है और इस तरह के नुकसान को पहले जैसा भी किया जा सकता है!

अगर इस स्थिति को ठीक करने के लिए बिना किसी काम वाले सर्विस वर्कर को तैनात करना ज़रूरी हो, तो तथ्य के बाद समय निकालकर यह पता लगाएं कि क्या गड़बड़ी हुई है. आने वाले समय में, यह पक्का करें कि सर्विस वर्कर सिर्फ़ उन अनुरोधों को हैंडल कर रहा है जिनकी उसे उम्मीद होती है. स्टेजिंग में समय-समय पर टेस्ट करें. साथ ही, सिर्फ़ भरोसा होने पर ही अपडेट डिप्लॉय करें.