Удаление рабочих с ошибками, Удаление рабочих с ошибками

Иногда развертывается сервис-воркер с ошибками, и тогда возникают проблемы. Например, работник службы может быть проанализирован во время регистрации и успешно завершить установку. Тем не менее, ошибочный код в событии fetch может привести к тому, что он не будет отвечать на запросы, что приведет к появлению пустой страницы. Другая возможность заключается в том, что разметка страницы активно кэшируется, и сервис-воркер возвращает только устаревшие ответы разметки от экземпляра Cache для последующих посещений.

Есть много причин, по которым сервисный работник может иметь неприятные последствия, и это страшная проблема на рабочем веб-сайте. Несмотря на это, не все потеряно. Есть способы исправить ситуацию и вернуться в нужное русло.

Развертывание неактивного сервисного работника

Все, что обычно требуется для борьбы с ошибочным сервис-воркером, — это развернуть базовый бездействующий сервис-воркер, который устанавливается и активируется немедленно без обработчика событий 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);
    });
  });
});

Этот сервис-воркер немедленно установит и активирует, вызвав self.skipWaiting() в событии install . При желании в событии activate можно развернуть дополнительный код для принудительной перезагрузки любых других открытых вкладок с помощью WindowClient , которым управляет сервисный работник.

Очень важно , чтобы неактивный сервисный работник не содержал обработчика событий fetch . Когда сервис-воркер не обрабатывает запросы, эти запросы передаются в браузер, как если бы сервис-воркер не присутствовал. После развертывания неработающего сервис-воркера его можно исправить и развернуть в качестве обновления позже.

Этот подход работает отчасти потому, что браузеры имеют строгие меры защиты от размещения сервис-воркеров в кэше HTTP , а также потому, что они выполняют побайтовые проверки содержимого сервис-воркера на наличие обновлений. Эти значения по умолчанию позволяют развернуть неоперативную замену неисправного сервисного работника, чтобы быстро устранить проблему.

Дополнительные меры, которые необходимо принять

Развертывания неработающего сервис-воркера должно быть достаточно для нейтрализации ошибочного работника, но при необходимости можно принять дополнительные меры.

Что делать, если вы не знаете URL-адрес старого сервис-воркера?

Иногда URL-адрес ранее установленного сервисного работника неизвестен. Это может быть связано с тем, что он имеет версию (например, в имени файла содержится хэш). В этом случае может возникнуть проблема с развертыванием неработающего сервис-воркера, который соответствует URL-адресу каждого старого сервис-воркера, который может быть зарегистрирован. Это противоречит лучшим практикам , поскольку разработчики, скорее всего, не будут помнить каждый хеш для каждой развернутой версии Service Worker.

К счастью, вместе с запросом сценария сервисного работника отправляется полезный заголовок HTTP-запроса: Service-Worker . На веб-сервере проверьте этот заголовок и перехватите запрос на обслуживание неработающего сервисного работника. Выполнение этой задачи зависит от используемого веб-сервера и внутреннего стека, поэтому обратитесь к документации соответствующего языка, чтобы узнать, как это сделать.

Что касается будущих развертываний сервис-воркеров, придерживайтесь неверсионных имен ресурсов (например, sw.js ). Это значительно упростит задачу в дальнейшем.

Установите заголовок Clear-Site-Data

Некоторые браузеры отменяют регистрацию всех сервисных работников для источника, если установлен заголовок ответа Clear-Site-Data со значением 'storage' . Однако при таком подходе следует учитывать несколько моментов:

• Имейте в виду, что при этом будет очищено все хранилище для соответствующего источника. Сюда входят localStorage , IndexedDB, sessionStorage и другие хранилища (но не HTTP-кеш для источника).
• Этот заголовок поддерживается не всеми браузерами .

Поскольку поддержка этого заголовка не является полной, в решении проблемы нельзя полагаться только на него. Поэтому лучше всего рассматривать Clear-Site-Data как меру, которую следует принять в дополнение к развертыванию неработающего сервисного работника.

Ущерб не является постоянным

Это может быть страшно, когда работа пользователя нарушается из-за сбоя в работе службы поддержки — особенно для крупных и известных веб-сайтов — но ущерб носит временный и обратимый характер!

Если для исправления ситуации необходимо задействовать неактивного сервисного работника, потратьте время постфактум, чтобы точно выяснить, что пошло не так. В будущем убедитесь, что сервисный работник обрабатывает только те запросы, которые он должен обрабатывать. Часто тестируйте промежуточную версию и развертывайте обновления только в случае уверенности.