После переустановки приложения push-уведомления перестали приходить. Как проверить, что сервер использует устаревший токен доставки?
Нужно сопоставить токен, полученный приложением после переустановки, с токеном, сохранённым на сервере, и проверить, какой из них используется при отправке. После переустановки токен push-доставки нельзя считать неизменным: приложение должно заново зарегистрировать его и передать серверу.
Проверка должна охватывать получение нового токена, его отправку на сервер, замену старого значения и фактический результат отправки через соответствующую push-платформу. Если сервер продолжает использовать прежний токен, уведомление может не доставляться даже при исправной сети и корректном тексте сообщения.
Push-уведомления изначально строились как посредническая доставка: приложение не обязано постоянно поддерживать собственное соединение с сервером. Система устройства принимает сообщение через инфраструктуру платформы, а затем передаёт его приложению или показывает пользователю.
Для адресации используется специальный токен регистрации приложения на конкретном устройстве или экземпляре приложения. Такой подход снижает требования к постоянной работе приложения, но делает актуальность токена отдельной частью жизненного цикла.
Переустановка удаляет локальное состояние приложения и создаёт новый экземпляр его регистрации в push-инфраструктуре. Даже если пользователь вошёл в тот же аккаунт, прежний токен нельзя автоматически считать действительным для нового экземпляра.
Риск возникает, когда сервер хранит токен только при первом входе пользователя или не заменяет старое значение новым. Тогда сервер может успешно принять запрос на отправку, но направить его по устаревшему адресу, а команда будет ошибочно искать причину в разрешениях, сети или интерфейсе уведомлений.
Сначала тестировщик фиксирует токен, полученный приложением до удаления, затем удаляет приложение, устанавливает его заново и сохраняет новый токен. Нужно проверить не только факт вызова регистрации, но и то, что новый токен передан серверу для того же пользователя или экземпляра установки.
На серверной стороне проверяют следующие свойства:
Важно проверять токен после каждого уведомляемого события регистрации, а не только после первого запуска. Токен может измениться и без переустановки, поэтому приложение должно передавать серверу актуальное значение при получении обновления от push-службы.
Для iOS доставка обычно проходит через APNs, для Android — через FCM либо совместимую инфраструктуру. Формат и правила обработки ошибок у платформ различаются, поэтому тестировщик должен анализировать ответ конкретного провайдера, а не считать HTTP-успешный ответ сервера гарантией показа уведомления.
Следует также разделять три результата: сервер принял запрос, push-провайдер принял сообщение и устройство показало уведомление. На последний результат влияют разрешения, режимы фокусировки, настройки канала уведомлений, состояние приложения и ограничения ОС. Эти факторы нужно проверять отдельно, чтобы не смешивать их с проблемой устаревшего токена.
После переустановки Android-приложения пользователь продолжал получать сообщения на старое устройство, но новое устройство уведомлений не показывало. В журналах приложения регистрация нового токена присутствовала, однако в базе сервера для пользователя оставался только прежний токен.
Рассматривались два варианта. Можно было хранить один токен на пользователя: это проще, но ломает доставку на нескольких устройствах. Можно было хранить набор токенов с признаком активности: модель сложнее, зато она соответствует ситуации, когда один аккаунт используется на нескольких установках.
Выбрали второй вариант. При получении нового токена сервер добавлял или обновлял запись конкретной установки, а при подтверждённо недействительном токене отключал только её. После этого уведомления доставлялись на новую установку, а другие устройства пользователя продолжали работать.
Нет. Сам факт изменения токена ещё не доказывает исправность цепочки. Нужно подтвердить передачу нового значения на сервер, его сохранение, выбор этого значения при отправке и успешную обработку ответа push-провайдера.
Кроме того, поведение токена не следует проверять по правилу «после каждой установки он обязан отличаться». Токены выдаются платформой, а приложение должно корректно обрабатывать получение актуального значения независимо от того, совпало оно с прежним или нет.
Пользователь может иметь несколько устройств или несколько активных установок приложения. Один токен описывает конкретную регистрацию, поэтому замена им предыдущего значения может отключить уведомления на другом устройстве.
Один токен допустим только при явно выбранной продуктовой модели «одно активное устройство на аккаунт». Даже в этом случае нужно определить, как система отзывает старую регистрацию и что происходит при повторном входе пользователя.
Обычно он означает принятие запроса сервером приложения или push-провайдером, но не гарантирует показ уведомления пользователю. Сообщение может быть отклонено позже, адрес может оказаться недействительным, а ОС может не показать уведомление из-за разрешений, настроек канала, режима фокусировки или ограничений фоновой работы.
Поэтому тест должен проверять наблюдаемую цепочку по этапам: актуальный токен, запись на сервере, результат провайдера и состояние уведомления на устройстве. Только такое разделение позволяет отличить проблему регистрации от ограничений отображения.