PWA не обновляется: новая версия ждёт открытые вкладки

Если после выпуска новой версии установленная PWA продолжает показывать прежний интерфейс, сначала проверьте состояние service worker и открытые окна приложения. Успешная сборка на сервере не доказывает, что конкретное устройство перешло на неё. Обновление может быть обнаружено и установлено, но оставаться в ожидании. При этом пользователь продолжает работать с уже открытой страницей.

Не начинайте с совета удалить приложение и все данные сайта. У сотрудника могут оставаться несохранённая форма и локальные черновики. Для поддержки задача состоит из двух частей: установить, какой переход задержался, и предложить проверенный способ продолжить работу. Здесь рассматривается управление выпуском собственной PWA, а не инструкция по очистке чужих устройств или обещание одинакового поведения всех браузеров.

Разделите серверный выпуск и версию на устройстве

Попросите разработчика показывать доступный поддержке идентификатор сборки интерфейса. Отдельно фиксируйте состояние регистрации service worker. Номер серверного выпуска, код уже открытой страницы и активный обработчик запросов могут описывать разные стороны ситуации. Одно поле «последняя версия» в панели администратора не отвечает на вопрос, что сейчас использует конкретный сотрудник.

Для учебного разбора назовём старую сборку А, новую — Б. Это условные обозначения, не реальные версии продукта. Сотрудник открыл форму в А, затем команда выпустила Б. Если в браузере уже появился ожидающий новый worker, это один случай. Если его нет, нужно исследовать обнаружение и установку, а не убеждать человека снова закрывать вкладки без основания.

Собирайте эти сведения на тестовом аккаунте или обезличенном примере. Поддержке не нужны реальные тексты заказов, пароли и содержимое личных документов. Достаточно версии, последовательности действий, состояний обновления и признака несохранённой работы. Такие данные помогают воспроизвести проблему без пересылки полного профиля браузера.

Что означает ожидание нового service worker

В руководстве web.dev описан обычный переход: установленное обновление ждёт, пока прежний worker перестанет контролировать клиентов. Обновление одной вкладки не всегда освобождает его, поскольку старая и новая страницы при навигации могут существовать с перекрытием. Поэтому бесконечное нажатие кнопки перезагрузки не является надёжной диагностикой.

Это объясняет конкретное состояние waiting, но не любую жалобу на старый экран. Если установка завершилась ошибкой, нужно разбирать её отдельно. Если страница получает устаревший файл другим путём, смена worker сама по себе ещё не подтверждает исправление. Просите показать наблюдаемый этап, а не называть любую задержку «кешем браузера».

Для владельца сервиса полезен короткий отчёт: обновление найдено, подготовлено, ожидает либо применено; у каких тестовых окон проверено поведение. Разработчик может представить технические состояния рядом с понятным описанием. Не превращайте приёмку в требование пользователю самостоятельно разбираться во всех инструментах браузера каждый раз после выпуска.

Закрытие вкладок требует подготовки

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

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

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

Принудительная активация не заменяет перезагрузку страницы

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

Метод clients.claim относится к получению контроля над клиентами в области worker. MDN отдельно описывает событие controllerchange при смене контроллера. Для проекта отсюда следует вопрос: что делает сама страница после такого события? Предлагает сохраниться, проверяет готовность и выполняет согласованный переход либо продолжает работу? Ответ должен находиться в реализации приложения.

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

Договоритесь о совместимости на время перехода

Рассмотрим предлагаемый процесс выпуска внутреннего кабинета. Пока часть сотрудников работает в А, сервер не должен неожиданно трактовать привычное поле как другую величину. Каким способом поддерживается совместимость, решает команда разработки. Для заказчика значим проверяемый результат: открытая до выпуска операция либо завершается правильно, либо заранее получает понятное требование обновиться.

Отдельный пункт — локальные данные. Если Б ожидает другую структуру черновика, нужен согласованный переход или явное ограничение. Недостаточно проверить чистую установку на новом телефоне: там отсутствует история, из-за которой и возникает риск. Возьмите тестовый профиль с данными предыдущей версии и проверьте именно путь обновления.

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

Проверьте выпуск в двух окнах

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

Повторите сценарий с временно недоступной сетью и последующим восстановлением связи. Не требуйте от приложения невозможного: сообщение об обнаруженной версии и возможность загрузить её ресурсы — разные события. Пользователь должен понимать, завершился переход или ещё ожидается действие. Окончательный критерий — новая версия открывается и согласованные данные доступны после повторного запуска.

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

Что включить в задачу на доработку

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

Принимать доработку стоит по переходу с реально установленной старой копии. В отчёте должны быть открытые окна, сохранённые данные и итоговая версия после запуска. Успешная новая установка проверяет другой путь. Разделение этих проверок помогает выпускать изменения предсказуемо и уменьшает число обращений «на сервере уже обновили, а у меня всё по-старому».