Deep link из push открывает не тот раздел: как исправить маршрутизацию

Переход из push проходит несколько этапов: провайдер доставляет payload, ОС передает действие приложению, код извлекает route, навигатор ждет инициализации и проверяет авторизацию. Если один этап теряет параметры или запускается слишком рано, приложение открывает главный экран вместо нужной карточки.

Проверьте три состояния отдельно: приложение закрыто, в фоне и открыто. Логируйте только тип маршрута и безопасный идентификатор. Сохраняйте pending deep link до готовности навигации и после входа пользователя продолжайте исходный переход.

Что проверить в первую очередь

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

• Сравните payload проблемного push в Android и iOS без персональных данных.
• Проверьте обработчики notification tap для cold, warm и foreground.
• Убедитесь, что route и ID присутствуют в data, а не только в display notification.
• Проверьте доступ пользователя к целевому объекту и поведение при истекшей сессии.

Почему возникает проблема

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

• При cold start обработчик вызывается до создания navigation container.
• Notification payload перехватывает системная оболочка и теряет custom data.
• Android intent filter или iOS universal link не соответствует host/path.
• После авторизации приложение забывает pending route и открывает home.
• Разные версии приложения ожидают разные имена полей payload.

Пошаговая диагностика

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

• Запишите source, app state, route type и результат каждого перехода.
• Отправьте тестовый push с минимальным data payload и известным ID.
• Проверьте getInitialMessage/initial notification и listener открытого приложения.
• Проверьте assetlinks.json или apple-app-site-association без редиректов и неверного MIME.
• Сравните таблицу маршрутов приложения с типами событий backend.

Как построить единый маршрутизатор входящих ссылок

Push, universal link, custom scheme и внутренний баннер должны преобразовываться в одну типизированную команду навигации. Тогда различается только источник, а проверка доступа и ожидание готовности выполняются одинаково.

• Parser валидирует route type, ID и версию payload.
• Pending route хранится до готовности навигатора и авторизации.
• Resolver проверяет существование объекта и право просмотра.
• Navigator открывает экран только после восстановления состояния приложения.
• Fallback показывает понятное сообщение, если объект удален или недоступен.

Как исправить проблему

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

• Перенесите обязательные параметры в data payload и версионируйте схему.
• Создайте единый parser/resolver для всех источников deep link.
• Сохраняйте pending route при cold start и перед экраном входа.
• Настройте intent filters/universal links для точных доменов и путей.
• Добавьте fallback для старых версий приложения и неизвестных типов.

Безопасный порядок внедрения

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

Как проверить результат

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

• Один push открывает нужный объект из closed, background и foreground.
• Пользователь без сессии после входа возвращается к исходной цели.
• Недоступный объект не раскрывает данные и показывает понятный fallback.
• Повторный tap не создает несколько одинаковых экранов в navigation stack.

Типичные ошибки при исправлении

• Проверять только приложение, уже открытое на главном экране.
• Передавать route исключительно в title/body уведомления.
• Открывать объект до проверки авторизации и tenant.
• Создавать отдельную несовместимую навигацию для каждого push-типа.

Как предотвратить повторение

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

• Поддерживайте контракт payload с версиями и примерами для backend.
• Добавьте автоматические тесты cold/warm start на основные маршруты.
• Контролируйте долю успешных opens и причины fallback.
• Не передавайте секретные или лишние персональные данные в push payload.

Что подготовить для технического разбора

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

Частые вопросы

Почему Android работает, а iOS открывает главную?

Платформы по-разному обрабатывают notification/data payload и жизненный цикл. Проверьте initial response и универсальные ссылки отдельно для iOS.

Что делать, если объект требует входа?

Сохранить pending route, провести авторизацию и после успешного входа повторно разрешить маршрут с проверкой доступа.

Когда нужна помощь специалиста

Если push-уведомления открывают не те экраны, я могу проверить payload и обработчики Android/iOS, построить единый deep-link router и исправить cold start, авторизацию и fallback-сценарии.