Push сайта не приходят: разрешение и подписка браузера

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

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

Начните с одного ожидаемого сообщения

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

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

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

Разрешение относится к текущему контексту браузера

Документация MDN описывает Notification.permission как текущее разрешение для origin. Значения granted, denied и default имеют разный смысл; default не означает полученное согласие. При диагностике сначала установите, доступен ли соответствующий механизм в выбранной среде, и только затем интерпретируйте состояние.

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

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

Наличие подписки проверяется отдельно

Метод PushManager.getSubscription получает существующую подписку выбранной регистрации service worker. По MDN он возвращает объект PushSubscription либо null, когда подписки нет. Это другой вопрос, чем состояние разрешения. Вызов чтения также не следует путать с созданием новой подписки или запросом согласия.

Для приложения важен контекст регистрации, который используется фактически. Случайно проверить другой вариант и показать положительный результат недостаточно. Исполнитель должен объяснить, какая регистрация участвует в доставке и к какому состоянию относится отображаемая диагностика. Конкретный код проверки выбирают по архитектуре, не копируя фрагмент из статьи без адаптации.

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

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

Серверная запись должна соответствовать текущей подписке

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

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

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

Неизвестный срок не означает гарантированную бессрочность

Свойство expirationTime может содержать время окончания либо null. Документация MDN не превращает отсутствие указанного срока в обещание вечной работоспособности. Поэтому одной проверки «дата не задана» недостаточно, чтобы перестать учитывать актуальность подписки и результаты попыток обращения к ней.

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

Сохраняйте различие между неизвестным сроком, отказом отправки и отсутствием сведений о показе. Эти состояния требуют разных действий. Автоматическое удаление всех записей с null может отключить рабочие подключения, а признание их заведомо действующими способно скрыть проблему. Решение опирается на документированные свойства и фактический путь приложения.

Сообщение, показ и чтение не являются одним событием

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

Для проверки клиентской части используйте нейтральное учебное содержание. Оно позволяет обсудить отображение и переход без риска раскрыть заказ на общем экране. Если уведомление открывает кабинет, доступ к соответствующей записи должен проверяться независимо. Само получение сообщения не должно становиться способом обхода обычных прав приложения.

Состояния открытого и закрытого приложения, ограничения устройства и доступность сети проверяют на согласованной матрице. Эта статья не устанавливает универсальное время доставки. В описании продукта лучше указать поддерживаемые условия и ограничения. Обзор приложений PWA помогает обсудить формат продукта, но не заменяет проверку конкретной push-интеграции.

Приёмка проходит по переходам и отказам

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

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