Push на двух устройствах: как проверить замену адреса

Уточните, какую запись проверяете

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

Далее выбран режим регистрационных токенов FCM. Firebase пока поддерживает его одновременно с регистрациями на основе FID, хотя token API помечены устаревшими. Команда должна подтвердить используемый режим. Firebase: управление регистрациями.

FID обозначает установку приложения; installation auth token служит другой задаче. Эти значения нельзя подставлять вместо регистрационного токена выбранной модели. Firebase: установки и идентификаторы.

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

Подготовьте одного клиента с двумя установками

Все обозначения ниже вымышлены. У C410 есть установки I11 и I12, у другого клиента C420 — I21. Адресные метки соответственно A1, B1 и C1; настоящих токенов в примере нет. У первого клиента сохранены принятые заказы O701 и O702, у второго — O801.

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

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

Воспроизведите замену раньше старого результата

1. На условной минуте 5 подготовлена попытка P17 для A1 с полностью корректным payload. В её доказательстве закреплены фактическое назначение, проект и приложение.
2. На минуте 10 та же подтверждённая I11 сообщает A2. По правилам модели A2 становится текущим, A1 получает отметку «заменён». I12 продолжает ссылаться на B1.

На минуте 12 приходит результат P17: UNREGISTERED для A1. В справочнике FCM это ошибка снятой регистрации; такой токен прекращают использовать. Firebase: коды ошибок.

В нашем реестре завершается только A1. Ссылка I11 на A2 остаётся, как и независимая ветвь I12 → B1. Обработчик не должен находить сегодняшний адрес установки и закрывать его вместо назначения, сохранённого у P17. Время получения результата не меняет предмет старой попытки.

Ожидаемый набор C410 после шага — A2 и B1; у C420 остаётся C1. Заказы и прежние предпочтения клиентов неизменны. Для проверки можно оставить A1 в обезличенной истории как завершённую запись: четыре строки истории содержат только три текущих назначения. Это учебная организация свидетельств, не предписание хранить реальные токены бессрочно.

Отделите непригодный адрес от ошибки сообщения

INVALID_ARGUMENT может означать ошибку содержимого запроса. Firebase допускает вывод о недействительной регистрации по этому коду только при полностью корректном payload. Условие проверки payload.

В отдельной ветви для B1 задан некорректный payload и получен INVALID_ARGUMENT: B1 сохраняется. При неизвестной корректности вывод также не сделан. Сначала нужен разбор данных ошибки; исправление сообщения само по себе не доказывает дефект адреса.

Другая ветвь начинается с исходного результата A2 + B1: при корректном запросе подтверждённый UNREGISTERED относится уже к B1. Тогда завершается B1, а A2 и C1 остаются. Отсутствующий новый адрес для I12 нельзя придумывать.

SENDER_ID_MISMATCH означает несовпадение отправителя. Результат из другого проекта либо приложения не закрывает наш случай; сначала устанавливают правильную область диагностики. Очистка соседних адресов не исправляет конфигурацию.

В рабочем листе оставьте три отдельных вывода: что установлено о конкретной записи, что установлено о запросе и что пока неизвестно. Для каждого нужен наблюдаемый факт и ответственный. Фраза «отправка упала» не объясняет, какую запись разрешено менять. Учебные ветви проверяйте независимо, каждый раз возвращая согласованное исходное состояние.

Проверьте свежесть и разрешение отдельными ветвями

Firebase рекомендует обновлять серверную временную отметку при каждом поступлении регистрации, даже если токен прежний. В нашей ветви повторный A2 на минуте 20 меняет отметку 10 на 20, сохраняя один текущий A2. Свежесть регистрации.

На Android 13+ показ обычных уведомлений требует отдельного разрешения POST_NOTIFICATIONS; отказ блокирует их, кроме предусмотренных исключений. Android: разрешение уведомлений.

В следующей независимой ветви I12 запрещает обычные уведомления. B1 остаётся текущей записью, но исключается из кандидатов для выбранного видимого уведомления. A2 сохраняется; C1 другого клиента не затронут. Сам этот отказ не является доказательством недействительности B1.

Из этой ветви нельзя выводить общий запрет контакта или новое рекламное разрешение. Реальную просьбу клиента соблюдают в её подтверждённой области; отдельный порядок разобран в руководстве по предпочтениям. Число подходящих адресов здесь не равно числу отправленных, доставленных или прочитанных сообщений.

Попросите показать, что плохая реализация не проходит

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

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

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