Usuwanie debugowanych instancji roboczych usługi

Czasami wdrażany jest nieprawidłowy skrypt service worker, a potem pojawiają się problemy. Na przykład skrypt service worker może zostać przeanalizowany podczas rejestracji i zakończyć instalację. Jednak nieprawidłowy kod w zdarzeniu fetch może sprawić, że nie będzie on odpowiadać na żądania, co doprowadzi do wyświetlenia pustej strony. Inną możliwą przyczyną jest agresywne zapisywanie znaczników strony w pamięci podręcznej, przez co w przypadku kolejnych wizyt skrypt service worker zwraca tylko nieaktualne znaczniki z instancji Cache.

Skrypt service worker może się odrobić na wiele sposobów, co stanowi straszny problem w witrynie produkcyjnej. Mimo to nie wszystko stracone. Istnieją sposoby, aby rozwiązać problem i wrócić na właściwe tory.

Wdrażanie skryptu service worker no-op

Żeby radzić sobie z błędnym mechanizmem Service Worker, wystarczy wdrożyć podstawowy skrypt service worker no-op, który instaluje się i aktywuje natychmiast bez modułu obsługi zdarzeń 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);
    });
  });
});

Uwaga: wskazówka: przy wdrażaniu skryptu service worker no-op upewnij się, że jego adres URL pozostaje niezmieniony. W przeciwnym razie skrypt service worker no-op będzie aktywny razem z nim, a problemy nie ustąpią.

Ten skrypt service worker zainstaluje i aktywuje natychmiast, wywołując metodę self.skipWaiting() w zdarzeniu install. Opcjonalnie można wdrożyć w zdarzeniu activate dodatkowy kod, aby wymusić ponowne załadowanie wszystkich innych otwartych kart za pomocą interfejsu WindowClient sterowanego przez skrypt service worker.

Bardzo ważne jest, aby skrypt service worker no-op nie zawierał modułu obsługi zdarzeń fetch. Gdy skrypt service worker nie obsługuje żądań, są one przekazywane do przeglądarki tak, jakby nie było żadnego skryptu service worker. Po wdrożeniu skryptu service worker bez działania można go naprawić i wdrożyć jako aktualizację później.

To podejście działa częściowo dlatego, że przeglądarki mają silne zabezpieczenia przed umieszczaniem skryptów service worker w pamięci podręcznej HTTP oraz przeprowadzają kontrole bajtów zawartości zawartości skryptu service worker pod kątem aktualizacji. Te ustawienia domyślne umożliwiają szybkie wdrożenie rozwiązania, które nie wymaga działania, aby rozwiązać problem z błędnym skryptem service worker.

Uwaga: przy ogólnym wdrażaniu skryptu service worker warto mieć pod ręką skrypt service worker, który w razie potrzeby można zastąpić innym. Planuj z wyprzedzeniem i upewniając się, że wszyscy członkowie zespołu wiedzą, jak postępować w przypadku wdrożenia skryptu service worker no-op, uniknąć problemów z kodowaniem po wdrożeniu.

Dodatkowe działania, które należy podjąć

Wdrożenie skryptu service worker no-op powinno wystarczyć do zneutralizowania błędu. W razie potrzeby możesz jednak podjąć dodatkowe działania.

A jeśli nie znasz adresu URL starego skryptu service worker?

Czasami adres URL wcześniej zainstalowanego skryptu service worker jest nieznany. Przyczyną może być jego obsługa wersji (np. nazwa pliku zawiera znak #). W tym przypadku może być wyzwaniem wdrożenie skryptu service worker no-op, który pasuje do adresu URL każdego starego skryptu service worker, który może być zarejestrowany. Jest to niezgodne ze sprawdzonymi metodami, ponieważ deweloperzy prawdopodobnie nie zapamiętają wszystkich haszów z każdej wdrożonej wersji skryptu service worker.

Na szczęście z żądaniem skryptu skryptu service worker wysyłany jest pomocny nagłówek żądania HTTP: Service-Worker. Na serwerze WWW sprawdź ten nagłówek i przechwyć żądanie, by zamiast tego udostępnić skrypt service worker no-op. W zależności od użytego serwera WWW i stosu backendu zapoznaj się z dokumentacją danego języka.

Jeśli chodzi o przyszłe wdrożenia mechanizmów Service Worker, trzymaj się nazw zasobów, które nie mają wersji (np. sw.js). Dzięki temu później sprawa będzie znacznie łatwiejsza.

Ustaw nagłówek Clear-Site-Data

Niektóre przeglądarki wyrejestrują wszystkie mechanizmy Service Worker ze źródła, jeśli ustawiony jest nagłówek odpowiedzi Clear-Site-Data o wartości 'storage'. Należy jednak pamiętać o kilku kwestiach:

• Pamiętaj, że spowoduje to wyczyszczenie całego miejsca na dane z powiązanego źródła. Obejmuje to localStorage, IndexedDB, sessionStorage i inne rodzaje pamięci masowej (ale nie pamięć podręczną HTTP źródła).
• Nie wszystkie przeglądarki obsługują ten nagłówek.

Ponieważ obsługa tego nagłówka nie jest całkowita, nie można polegać tylko na nim w rozwiązaniu problemu. Dlatego najlepiej jest traktować Clear-Site-Data jako środek oprócz wdrożenia skryptu service worker no-opera.

Uszkodzenie nie jest trwałe

Źle zakłócone działanie użytkownika przez podejrzany skrypt service worker (zwłaszcza w przypadku dużych i znanych witryn) może być niepokojące – ale szkody są tymczasowe i odwracalne.

Jeśli w celu rozwiązania sytuacji konieczne jest wdrożenie skryptu service worker no-opera, poświęć trochę czasu, aby dowiedzieć się, co poszło nie tak. W przyszłości upewnij się, że skrypt service worker będzie obsługiwać tylko te żądania, które powinien. Często testuj aktualizacje na etapie przejściowym i wdrażaj aktualizacje tylko po uzyskaniu pewności siebie.