Помилки під час відправлення мобільних push-повідомлень
У розробці мобільних додатків помилки та проблеми неминучі, особливо коли справа стосується таких складних сервісів, як Firebase та APNS.
В цій статті розглядаються поширені сценарії помилок, їх причини та способи вирішення.
На відміну від мобільних push-повідомлень, для Email єдиного переліку кодів помилок немає — конкретні коди й формулювання залежать від поштового провайдера одержувача.
| Помилка | Можлива причина | Рішення |
|---|---|---|
| Device token not registered | Помилка означає, що токен не валідний. При використанні Firebase і для IOS і для Android, можуть прострочитись сертифікати APN додані до Firebase. Або сертифікати згенеровані не для того оточення, до якого потрібно. Коли до проекту в FCM додається Apple застосунок, то треба окремо для кожного оточення завантажити сертифікати й може таке бути, що для development оточення використовується production сертифікат, чи навпаки. | Перевірити дійсність сертифікату і його відповідність оточенню. |
| The authenticated sender ID is different from the sender ID for the registration token | Проблема може бути з service аккаунтом Firebase. | Можна спробувати розширити права у service аккаунті. |
| Токен згенерований в одному проекті firebase, а спроба відправити пуш з іншого. Можливо токен з тестового оточення використовується на продакшені чи навпаки. | Налаштувати відповідно правильне використання токенів. | |
MOB_PUSH_GENERAL_ERROR | Помилка немає опису з боку APNS сервісу і може свідчити про збій зі сторони сервісу APNS. | Зверніться до нашої підтримки для детального аналізу. |
| No more information is available about this error | Немає інформації про помилку. | Зверніться до нашої підтримки для детального аналізу. |
| Request parameters were invalid | В адмінці обрали APNS для пушів, але передача контактам з SDK налаштована FCM токенів, або навпаки. | Варіанти рішень:
|
InvalidProviderToken | Маркер автентифікації APN, який використовується для автентифікації за допомогою APN для надсилання сповіщень, могло бути відкликано в Центрі розробників Apple. | Створити новий APNs Auth Key. |
| Неправильне налаштування p8 сертифікату. | Перевірити налаштування сертифіката. | |
badDeviceToken | Помилка виникає, коли токен APNs, виданий для sandbox-середовища, використовується в production, або навпаки. Збірка, підписана dev-сертифікатом, отримує токен sandbox-середовища. | Тестуйте пуш-повідомлення на збірці з TestFlight або App Store — її токен належить production-середовищу. |
| Invalid registration token/The registration token is not a valid FCM | Додаток налаштований через FCM, але у контакта APN-токен, і навпаки. При отриманні такої помилки токен автоматично видаляється. | Налаштувати FCM/APN. |
TopicDisallowed | Ця помилка може виникати під час використання токенів APN, коли ідентифікатор пакета в налаштуваннях push-сповіщень eSputnik (пов’язаний із файлом AuthKey .p8) не збігається з ідентифікатором пакета додатка, де тестується push-сповіщення. | Порівняйте значення, вказане в полі Тема під час створення застосунку в адмінпанелі eSputnik, з ідентифікатором пакета застосунку, де тестується push-сповіщення. |
Усунення проблем: середовища Sandbox і Production на iOS
BadEnvironmentKeyInToken і badDeviceToken означають одне: токен і середовище не збігаються.
APNs Auth Key із прапорцем Sandbox & Production — це один ключ для обох середовищ, але самі середовища лишаються окремими: токен, виданий debug-збірці, працює лише в sandbox, а токен збірки з TestFlight чи App Store — лише в production. Сам по собі ключ не робить обидва середовища робочими одночасно.
Тому токени debug-збірок можуть повертати ці помилки. Щоб перевірити пуші, використовуйте збірку з TestFlight або App Store.
Статуси, які повертає API
Для каналу мобільних пушів ресурс Get single message status повертає один із таких статусів: ERROR, DELIVERED, READ, CLICKED, EXPIRED, IN_QUEUE, PENDING. Статус READ не надходить із пристрою: SDK не може надійно визначити прочитання, тому система виводить READ із зафіксованого кліку.
У мобільного пуша з прив'язаним In-App окремих статусів In-App немає: клік по самому пушу статусу не додає, а клік по кнопці In-App зараховується пушу як READ і CLICKED.
Причина конкретної невдалої відправки приходить у полі statusDescription — у вебхуках і в експорті в BigQuery.
Про статус «В процесі» (Pending)
Статус В процесі (Pending) означає, що після відправлення push-повідомлення не отримано ані статусу доставлення, ані помилки. Типова причина — застосунок видалено з пристрою або сповіщення вимкнено, а застосунок більше не відкривали: токен у контакта залишається, але статуси за відправленнями не надходять. Для діагностики перевірте давність подій активності контакту в застосунку — наприклад, події ApplicationOpened.
На вкладці Активність контакту в категорії Розсилки цей самий стан відображається як Невідомо: сервіс доставлення прийняв пуш без помилки, але застосунок не надіслав статусу доставлення. Статус Невідомо не видаляє токен — його прибирає лише помилка під час відправлення.
Такі поодинокі випадки — норма. Якщо ж у статусі В процесі лишається велика частка контактів у кількох розсилках поспіль, це ознака помилки в налаштуванні інтеграції застосунку або того, що багато користувачів відхилили підписку на сповіщення чи видалили застосунок.
Про помилку Device token not registered
Помилка Device token not registered виникає під час відправлення і після неї токен автоматично видаляється — але це не обов'язково означає, що застосунок було видалено з пристрою: токен міг стати недійсним з інших причин. Видалений токен не може знову стати валідним: коли користувач повторно підписується на пуш-сповіщення, реєструється новий токен. Чіткого сегмента чи фільтра, який виокремлює контакти саме з цією причиною втрати токена, немає.
Коли перевипускається push-токен
Токен мобільних push не перевипускається щоразу при запуску застосунку і не пов'язаний з авторизацією користувача. Новий токен генерується при першому запуску після встановлення, при перевстановленні застосунка, якщо попередній токен визнано недійсним, або якщо застосунок примусово видалив токен у коді. В інших випадках SDK використовує наявний.
На iOS після перевстановлення застосунку SDK отримує новий Device ID, якщо на пристрої не залишилося інших застосунків того самого розробника; якщо такі є, Device ID зберігається. SDK не може визначити, що застосунок видалили, тому, коли користувач входить в акаунт, у контакті з'являється ще один пристрій із новим токеном. Попередній токен при цьому не видаляється: його прибирає лише помилка під час відправлення на нього.
На iOS токен може змінюватися кілька разів на день, якщо режим отримання токена в SDK не відповідає тому, як застосунок його передає. У режимі .automatic SDK сам бере APNs-токен, тому, якщо застосунок додатково передає FCM-токен, токен контакта перезаписується то одним, то іншим, і надсилання завершуються помилкою. Як вибрати режим, дивіться у налаштуваннях iOS SDK, крок 2.
Усунення проблем: пристрій зареєстровано без push-токена
Іноді SDK успішно реєструє deviceID для контакту, але push-токен не прив'язується, навіть якщо користувач надав дозвіл на сповіщення. Перевірте наступне:
- Помилка реєстрації Firebase — дозвіл надано, але Firebase не повернув токен через мережеву помилку під час реєстрації; повторна спроба зазвичай вирішує це.
- Відсутній push-entitlement у provisioning profile (iOS) — provisioning profile застосунку має включати entitlement для push-сповіщень, інакше APNs не видасть токен.
Push-токени: реєстрація та видаленняЦе нормально, коли SDK надсилає кілька запитів на реєстрацію поспіль під час ініціалізації (наприклад, спочатку лише з
deviceID, а потім — з push-токеном, коли він стає доступним).Токени видаляються лише за результатом спроби відправлення: коли доставка повертає помилку недійсного токена (наприклад, «Device token not registered»), система автоматично видаляє такий токен.
Фонового або планового очищення токенів без спроби відправлення немає, тому недійсний токен, на який нічого не надсилали, залишається в акаунті до наступної відправки.
Updated 6 days ago