En esta brillante charla, Alexander Pope: Brote de ServiceWorkers: index-sw-9a4c43b4b47781ca619eaaf5ac1db.js | JSConf EU 2017 : El presentador tiene una situación en la que se instala un trabajador de servicio roto y está atascado en el estado roto. El presentador intenta un interruptor de interrupción y un trabajador de servicio vacío para remediarlo, pero todavía hay algunos navegadores permanentemente infectados. Estoy tratando de entender por qué sucedió y no hacer algo similar.

Aquí está su código (de 22m:57s):

 function onInstall(event) { event.waitUntil( install(config.version, config.assets) .catch((err) => { reportError(err); // Ok, you know what you're doing, Installing now.... }) ); }

Se atasca porque dentro de la llamada para install usa cache.addAll() , pero hace mucho tiempo que Chrome no admitía cache , por lo que este error nunca apareció y el navegador pensó que estaba instalado correctamente.

Ahora el navegador es responsable de obtener el archivo sw.js y verificar si su byte es diferente al trabajador instalado actualmente. El código para registrar el nuevo archivo sw.js está fuera del archivo del trabajador del servicio. Esto significa que incluso si un trabajador de servicio está dañado, el navegador debería poder buscar el nuevo, determinar su diferencia, registrarlo y activarlo (eventualmente). El archivo sw.js más nuevo podría verificar la presencia de la API de cache . Entonces, ¿por qué hay algunos clientes todavía en un estado roto?