Como remover service workers com bugs

Às vezes, um service worker com bugs é implantado, então há problemas. Por exemplo, um service worker pode ser analisado no momento do registro e concluir a instalação com sucesso. No entanto, um código com bug em um evento fetch pode fazer com que ele não responda a solicitações. resultando em uma página em branco. Outra possibilidade é que a marcação da página seja armazenada em cache de forma intensa, e um service worker só retorna respostas de marcação desatualizadas de uma instância Cache para visitas subsequentes.

Há muitas maneiras de um service worker ter um trabalho ruim, e esse é um problema assustador de um site de produção. Mesmo assim, nem tudo está perdido. Há maneiras de corrigir a situação e colocar tudo de volta nos eixos.

Implantar um service worker de ambiente autônomo

Para lidar com um service worker com bugs, basta implantar uma versão Service worker no-op que é instalado e ativado imediatamente sem um manipulador de eventos 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);
    });
  });
});

Este service worker será instalado e ativado imediatamente chamando self.skipWaiting() no evento install. Outra opção é implantar outro código no evento activate para forçar o recarregamento de qualquer outra guia aberta com um WindowClient que o service worker esteja controlando.

É muito importante que um service worker de ambiente autônomo não contenha manipulador de eventos fetch. Quando um service worker não gerencia solicitações, essas solicitações passam para o navegador como se não houvesse um service worker. Depois que um service worker de ambiente autônomo é implantado, o service worker com bugs pode ser corrigido e implantado mais tarde como uma atualização.

Essa abordagem funciona em parte porque os navegadores têm fortes proteções contra a colocação de service workers no cache HTTP e porque eles executam verificações byte por byte do conteúdo de um service worker para atualizações. Esses padrões possibilitam a implantação de um substituto de ambiente autônomo para um service worker com bugs para corrigir o problema rapidamente.

Outras medidas a serem tomadas

Implantar um service worker autônomo deve ser suficiente para neutralizar um com bugs, mas é possível tomar outras medidas se necessário.

E se você não souber o URL do service worker antigo?

Às vezes, o URL de um service worker instalado anteriormente é desconhecido. Isso pode ter acontecido porque ele tem controle de versão (por exemplo, contém um hash no nome do arquivo). Nesse caso, pode ser um desafio implantar um service worker de ambiente autônomo que corresponda ao URL de cada service worker antigo que possa estar registrado. Isso vai contra as práticas recomendadas, porque é provável que os desenvolvedores não se lembrem de cada hash de cada versão do service worker que foi implantada.

Felizmente, um cabeçalho de solicitação HTTP útil é enviado com uma solicitação para um script de service worker: Service-Worker No servidor da Web, verifique esse cabeçalho e intercepte a solicitação para exibir um service worker autônomo. Isso depende do servidor da Web e da pilha de back-end usados, então consulte a documentação da linguagem relevante para saber como fazer isso.

Para implantações futuras do service worker, use nomes de recursos sem controle de versões (por exemplo, sw.js). Isso tornará as coisas muito menos complicadas mais tarde.

Definir um cabeçalho Clear-Site-Data

Alguns navegadores cancelarão o registro de todos os service workers de uma origem se um O cabeçalho de resposta Clear-Site-Data com um valor 'storage' foi definido. No entanto, há algumas coisas que você precisa considerar sobre essa abordagem:

• Isso vai limpar todo o armazenamento da origem associada. Isso inclui localStorage, IndexedDB, sessionStorage e outro armazenamento, mas não o cache HTTP da origem.
• Esse cabeçalho não é compatível com todos os navegadores.

Como o suporte a esse cabeçalho não é total, ele não pode ser usado sozinho para corrigir o problema. Portanto, é melhor ver Clear-Site-Data como uma medida a ser tomada além de implantar um service worker autônomo.

O dano não é permanente

Pode ser assustador quando a experiência do usuário é prejudicada por um service worker com bugs, especialmente para sites grandes e conhecidos, mas o dano é temporário e reversível!

Se for necessário implantar um service worker autônomo para corrigir a situação, reserve um tempo após o acontecimento para descobrir exatamente o que deu errado. No futuro, garanta que um service worker processe apenas as solicitações esperadas. Testar com frequência no preparo e implantar atualizações somente quando tiver confiança.