Telegram-бот не получает часть событий: проверка allowed_updates без сброса очереди
Как различить фильтр обновлений Telegram, сбой вебхука и ошибку обработчика. Неразрушающая проверка пропавших сообщений, callback и событий участников.
Telegram-бот не получает часть событий: проверка allowed_updates без сброса очереди
Если одни события доходят до Telegram-бота, а другие пропали, сначала проверьте подписку на типы обновлений и маршрутизацию в приложении. Параметр allowed_updates выбирает типы событий, но не даёт доступ к чату и не подтверждает обработку в CRM. Если параметр не передать, сохранится прежняя настройка. Пустой список тоже не означает буквально все существующие типы обновлений.
Разбор предназначен для владельца собственной интеграции Telegram Bot API с CRM. Нужен разрешённый доступ к её настройкам, обезличенным диагностическим данным и тестовой среде. Это не описание проверенной встроенной функции 24go.site. Ниже предложен эксплуатационный план проверки, а не отчёт об испытании действующего бота или CRM при подготовке статьи. Для чтения плана рабочий токен не требуется.
Сначала уточните, чего именно нет
За словами «перестали приходить сообщения» могут стоять разные сбои. Обычное текстовое сообщение представлено обновлением message, нажатие inline-кнопки с callback — callback_query, публикация канала - channel_post. Это разные поля объекта Update. Если обработчик читает только update.message, он не обработает все события, которые сервер корректно доставил приложению.
Сформулируйте наблюдение точно: человек написал новое текстовое сообщение тестовому боту в личном чате в известное время, но приёмник не сохранил соответствующее событие. Сравните с другим наблюдением: событие сохранено, но лид не появился. Во втором случае поиск уже выходит за границу доставки Telegram. Запишите тип события, тип чата и последний подтверждённый этап обработки, а не всю переписку или телефон клиента.
Для управляемой проверки используйте уникальную метку без персональных данных. Исключите тестовую учётную запись из производственных продаж через согласованную тестовую конфигурацию. Диагностика не должна случайно запустить настоящую цепочку последующих сообщений. Если изоляция не подтверждена, остановитесь до отправки теста: сначала ответственный за интеграцию должен подготовить безопасную среду.
Между действием человека и лидом несколько независимых границ
Путь удобно представить так: допустимость события → подписка → транспорт → приёмник → диспетчер → исполнитель CRM. Допустимость означает, что бот вправе получить этот вид события в этом чате. Подписка разрешает соответствующий тип обновления. Транспорт доставляет его через вебхук или polling. Приёмник проверяет запрос и надёжно сохраняет принятые данные. Диспетчер выбирает прикладной обработчик, а исполнитель делает разрешённую бизнес-операцию.
Изменение одной границы не исправляет остальные. Добавление message в список подписки не открывает произвольные групповые разговоры. Дополнительные права в группе не заставят диспетчер обрабатывать callback_query. Успешный HTTP-ответ не доказывает сохранение события. Сохранённое событие ещё не означает, что CRM зафиксировала новую запись.
В FAQ Telegram описаны правила privacy mode для обычных групповых сообщений, включая команды, адресованные боту, и ответы. Применяйте их в указанных границах. В актуальном журнале изменений API также описаны новые возможности общения между ботами и guest mode, тогда как старые формулировки FAQ шире. Поэтому исходный тест здесь - сообщение человека в обычном личном чате. Мы не используем другого бота, гостевые сообщения и не утверждаем, что все нынешние режимы общения работают одинаково.
Что означает allowed_updates и где исключения
В текущих контрактах setWebhook и getUpdates описаны три важных варианта:
| Входная настройка | Документированный смысл | Следствие для диагностики |
|---|---|---|
| Параметр отсутствует | Используется предыдущая настройка | Повторный деплой без поля не сбрасывает фильтр |
Явный список, например ["message", "callback_query"] | Подписка на перечисленные типы | Остальные необходимые типы требуют отдельного решения |
Пустой список [] | Все типы, кроме chat_member, message_reaction, message_reaction_count | Нельзя называть такой режим неограниченной подпиской |
chat_member бот должен быть администратором, а тип нужно запросить явно. События реакций также имеют собственные документированные условия. Не включайте все возможные типы как универсальный способ ремонта: для каждого нужны обработчик, политика доступа и решение о хранении данных.
В личных чатах my_chat_member относится к блокировке или разблокировке бота пользователем. Это не то же самое, что изменение статуса другого участника через chat_member. Если программа ждёт одно событие, а подписана на другое, перезапуск транспорта не устраняет расхождение. До правки настройки сопоставьте нужный бизнес-сигнал с точным полем Update.
Новая настройка не меняет задним числом обновления, созданные до вызова метода. Telegram отдельно предупреждает, что нежелательные обновления ещё некоторое время могут приходить. Приёмник должен уметь безопасно отклонять, игнорировать или сохранять такие старые события согласно своей политике. Успешный ответ на изменение конфигурации не доказывает, что каждый следующий запрос немедленно будет иметь только новый состав полей.
Посмотрите состояние, не переключая транспорт
Для бота с вебхуком уполномоченный оператор может посмотреть getWebhookInfo через существующий безопасный инструмент администрирования. Метод сообщает URL вебхука, число ожидающих обновлений и необязательные сведения об ошибках и подписке. Перед отправкой результата в поддержку проверьте его: адрес может раскрыть внутреннюю маршрутизацию или чувствительную часть пути. Не вставляйте токен бота, полный URL команды или секретный заголовок в тикет.
Непустой URL показывает наличие настройки вебхука, но не исправность текущего приёмника. Число ожидающих обновлений — состояние доставки на конкретный момент, а не размер очереди вашего приложения. Ноль не доказывает, что действие пользователя было допустимо, прошло фильтр, доставлено и обработано. Необязательные поля последней ошибки описывают наблюдавшуюся ошибку, а не полную историю всех попыток или обязательную текущую аварию.
Если URL пустой, сначала выясните, кто управляет polling и где записаны его настройки. Не запускайте второй потребитель обновлений на своём ноутбуке ради проверки. Документация говорит, что getUpdates не работает при установленном исходящем вебхуке. Кроме того, polling подтверждает обновления с помощью offset: случайный тест способен вмешаться в обработку приложения. Переключение транспорта — отдельное плановое изменение, а не безвредный просмотр пропавших типов событий.
Сопоставьте три источника: желаемую подписку в конфигурации деплоя, фактический запрос регистрации или polling, который делает работающая интеграция, и наблюдаемое состояние в разрешённом административном контуре. Фреймворк может сформировать запрос самостоятельно, поэтому одного рукописного файла настроек недостаточно. В отчёт записывайте версии конфигурации, не значения секретов.
Как выбрать следующую проверку по наблюдению
| Наблюдение в изолированном тесте | Следующая граница проверки | Чего оно ещё не доказывает |
|---|---|---|
| Личное сообщение человека отсутствует на входе | Идентичность бота, подписка и транспорт | Что его отбросила CRM |
| Сообщение приходит, callback отсутствует | Подписка callback_query и диспетчер callback | Что вся доставка Telegram сломана |
| Личный тест работает, обычный групповой текст нет | Допустимость в группе, privacy mode и задуманный сценарий | Что обязательно нужны более широкие права |
| В принятом Update есть нужное поле, обработчик не запущен | Прикладной маршрутизатор и поддерживаемая схема | Что сброс вебхука исправит код |
| Обработчик запущен, результата CRM нет | Квитанция исполнителя, бизнес-правила и сверка CRM | Что Telegram потерял событие |
| После смены фильтра пришло старое ненужное событие | Время создания и документированный переход | Что новая подписка обязательно проигнорирована |
За проверку подлинности входящего запроса отвечает отдельная инструкция по webhook secret. Повторы уже принятых событий и неопределённую запись в CRM разбирает руководство по идемпотентности. Эти меры остаются нужными, но отвечают на другие вопросы, чем подписка на тип обновления.
Порядок управляемого изменения и приёмки
- Запишите необходимые бизнес-события и сопоставьте каждое с точным полем Update. Назначьте ответственного за обработчик. В предложенный список включите уже необходимые типы: нельзя незаметно убрать работающий сценарий.
- Сохраните обезличенное исходное состояние: владельца транспорта, версию активной конфигурации, доступные доказательства подписки и наблюдаемые этапы. Частные адреса и секреты оставьте в предусмотренном хранилище, а не в отчёте об инциденте.
- Проверьте изменение в обычном процессе развёртывания интеграции. Параметры регистрации не ограничиваются списком событий. Сохраните согласованные endpoint, сертификат и аутентификацию, не собирайте новую команду по общему примеру из статьи.
- Примените через этот процесс только согласованную правку подписки. Не включайте
drop_pending_updates, чтобы убрать ошибку: документированное назначение параметра — удаление ожидающих обновлений, а не исправление маршрутизации. - В изолированной среде создайте новое личное сообщение человека и каждое дополнительное необходимое взаимодействие. Раздельно проверьте поле события, надёжную квитанцию приёмника, выбранный обработчик и тестовый результат следующего этапа.
- Повторите ранее работавший тип события как регрессионный тест. Появление callback не является успехом, если после правки перестали обрабатываться сообщения. Наблюдайте старые события очереди, не считая само их присутствие признаком неисправной настройки.
- Зафиксируйте результат и оставьте настройку либо откатите её тем же согласованным способом. Откат - ещё один переход конфигурации: он не возвращает уже удалённые события и не гарантирует ретроспективную доставку исключённых типов.
message, попасть в назначенный тестовый обработчик и привести к ожидаемой тестовой записи либо явному решению не писать данные. Для callback нужна отдельная квитанция и собственный результат проверки прав. Этот предложенный план не содержит гарантии сроков доставки и не выдаётся за выполненную сетевую проверку.
Что написать в отчёте об инциденте
Закрывайте задачу самым узким подтверждённым выводом: какой тип отсутствовал, на какой границе был сбой, что поменяли и какие новые тесты прошли. Приложите обезличенные метаданные и ссылки на ревизии конфигурации. Если исправлено только расхождение подписки, так и напишите: это не подтверждение исправности всей воронки продаж.
Если доказательства заканчиваются на приёмнике, результат последующих этапов остаётся непроверенным. Нет разрешённого доступа к администрированию бота - укажите этот блокер, не заимствуйте чужие учётные данные и не удаляйте вебхук. Если неясна допустимость групповых сообщений, отделите исходный личный тест от будущей проверки прав. В неактивном чате исправный бот может молчать, а действующий вебхук способен передавать события сломанному исполнителю. Конкретный вопрос о пропавшем событии решается наблюдением на нужных границах, а не общим перезапуском.