Бот не получает новые сообщения: проверка webhook, очереди и прав канала

Зафиксируйте тестовый запрос

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

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

Telegram: что проверить отдельно

Официальный Bot API даёт метод `getWebhookInfo`. Он показывает установленный URL, количество ожидающих обновлений и сведения о последних ошибках. Проверьте, что адрес соответствует рабочей среде, а не старому тестовому серверу. Если вы используете `getUpdates`, действующий webhook мешает этому режиму; они взаимоисключающие.

При webhook сервер должен корректно подтверждать приём. Долгая генерация ответа не должна удерживать входящий запрос без контроля: надёжнее быстро сохранить событие и обрабатывать его в очереди. Telegram может повторить доставку при неуспешном ответе, поэтому обработка одного `update_id` должна быть защищена от дублей.

Карта симптомов

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

Как восстановить поток безопасно

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

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

Когда проблема считается закрытой

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

Если проблема случается только иногда

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

Если канал повторяет событие, а ваш обработчик отвечает ошибкой, нужно видеть оба факта в журнале. Без этого команда начнёт спорить, «на чьей стороне проблема», вместо восстановления сообщений.

Запасной маршрут для клиента

При недоступности ИИ возможность связаться с компанией должна остаться. Если исходный канал работает, сохраните обращение и дайте короткое уведомление о ручной обработке. Если сам канал не доставляет события, разместите рабочий альтернативный контакт там, где клиент его увидит. Не показывайте фразу «ваша заявка принята», пока система не сохранила её в надёжной очереди или CRM.

Пример журнала одного сообщения

Для тестовой фразы полезно видеть короткую цепочку: 12:03:10 канал отправил событие; 12:03:10 сервер подтвердил приём; 12:03:11 событие записано в очередь; 12:03:14 обработчик сформировал ответ; 12:03:15 исходящее сообщение принято каналом. Время и идентификатор каждого шага помогают найти место разрыва. Если журнал обрывается после подтверждения каналу, ищите очередь; если после генерации, проверяйте исходящую отправку.

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

Когда канал прислал событие, но ответа быть не должно

Не каждое событие требует сообщения клиенту. Некоторые относятся к изменению статуса, техническому подтверждению или редактированию старой реплики. Обработчик должен фильтровать их явно и записывать причину пропуска. Если он отправляет на каждое событие запрос к модели, бот может отвечать на системные сигналы или создавать лишние карточки CRM. При диагностике «нет ответа» сначала уточните тип события: для некоторых типов отсутствие сообщения — правильный результат.

Если после восстановления появляются повторы, проверьте защиту от двойной отправки.