Граничные случаи service worker: version skew, долговременность и ловушка навигации

Вы деплоите service worker, который раздаёт кеш app shell по стратегии cache-first. Через неделю деплоите исправление бага. Часть пользователей никогда его не получит — они продолжают получать сломанный закешированный shell при каждой перезагрузке, и никакой кнопки восстановления для обычного пользователя не существует.

Проблема обновления и version skew

Кеш ресурсов service worker привязан к версии его кода. При деплое версии N+1 открытая страница может работать с воркером версии N, пока HTML версии N+1 уже задеплоен — или наоборот. Если воркер раздаёт cache-first app.js версии N, а HTML ожидает app.js версии N+1, получается runtime-ошибка из-за несовпадающих модулей.

Надёжный паттерн:

1. Content-hash каждое имя файла ресурса (app.4f3a1c.js). Старые и новые ресурсы сосуществуют в кеше без коллизий.
2. Version-tag имена кешей (cache-v3, cache-v4). Pre-cache весь набор ресурсов каждого деплоя под version tag.
3. В activate удалять только устаревшие кеши — кеши, чей version tag не является текущим. Делайте это после clients.claim(), чтобы ни одна контролируемая страница не потеряла ресурсы в середине сессии.
4. Раздавать навигационные запросы network-first (или по выделенному маршруту app-shell), чтобы пользователи всегда получали HTML, консистентный с активным воркером.

Тот же класс бага применим к sw.js самому по себе: браузеры кешируют файл воркера по умолчанию до 24 часов. Современная практика — отдавать sw.js с заголовком Cache-Control: no-cache, чтобы браузер всегда перепроверял его на навигации.

Service workers не являются долговременными

Браузер агрессивно убивает idle service worker — часто в течение секунд после завершения fetch-события — и перезапускает при следующем событии. Любое состояние в module-level переменной исчезает при перезапуске. Это частый источник багов:

• Счётчик запросов в полёте.
• Кеш ожидающих промисов.
• WebSocket-соединение в глобальной переменной.

Всё испаряется. Постоянное состояние должно жить в IndexedDB или Cache API.

Долгоживущая работа внутри обработчика события должна быть обёрнута в event.waitUntil(promise) — это говорит браузеру: «не убивай меня, пока этот промис не завершится». Забыть waitUntil — значит браузер может завершить воркер на полпути, и background sync, push-обработка, заполнение кеша молча не завершатся.

Перехват навигации и опасность app-shell

Самый мощный — и самый опасный — паттерн service worker: перехват навигационных запросов. fetch-обработчик ловит запрос на HTML-документ и возвращает закешированный app shell. Это даёт мгновенную загрузку, но создаёт класс багов, иначе невозможных.

Ловушка: если вы задеплоите баг в app shell и закешируете его с cache-first, каждый повторный визит будет раздавать сломанный shell из кеша, минуя сеть, где лежит исправление. Пользователь не может выбраться обычной перезагрузкой.

Защита многоуровневая:

1. Навигационные запросы — network-first с коротким таймаутом (~3 с, с откатом на кеш). Это гарантирует, что исправление дойдёт до пользователей при первой успешной загрузке.
2. Держите kill switch — версионированный эндпоинт, который воркер проверяет при activate или периодически. По сигналу вызывает self.registration.unregister() и удаляет кеши. Это позволяет удалённо отсоединить сломанный service worker от всех клиентов.
3. Никогда не кешировать навигацию только из кеша. Всегда должен быть сетевой путь.

Сломанный service worker, задеплоенный широко — это инцидент stop-the-deploy, потому что обычные пользователи не имеют кнопки восстановления: они не могут открыть DevTools, не могут очистить данные сайта. Единственный выход — kill switch или свежий деплой, который старый воркер подхватит при следующей активации.