У бота есть аватарка, имя, описание, в чате остаётся отправленная команда /start — а ответа нет. Вся наружная атрибутика исправного цифрового работника предъявлена, и, если судить по ней, он должен сидеть на месте и перебирать заявки, хотя самого работника, кажется, вынесли через чёрный ход вместе со стулом. Назову попытку судить о здоровье программы по этой картинке «аватарочной диагностикой».
Аватарка на посту.
В FAQ Telegram устройство бота описано без мистики: учётную запись, созданную через BotFather, надо соединить с программой на сервере через API. У аккаунта и программы разные обязанности. Поэтому существование первого ничего не доказывает о состоянии второй. Я предлагаю искать место, до которого дошло конкретное сообщение, а не освежать лицо у молчащего собеседника.
Для начала я бы записал время проверки, точный адрес бота и действие, после которого наступает тишина. Команда /start в личном чате, нажатие кнопки, отправка текста после вопроса — разные события. Лучше выбрать тест без настоящего заказа и оплаты. Если меню появляется, но следующий шаг зависает, это уже полезнее диагноза «всё умерло». Сохранился работающий участок, от которого можно двигаться дальше.
Именно здесь стоит остановить руку, потянувшуюся к общему перезапуску. Я не знаю, что сломалось у вашего бота, пока нет его настроек и следов ошибки. Сервер, получение сообщений и обработчик конкретной кнопки пока только версии. Перезапуск допустимо обсуждать после сохранения журналов и понимания, что именно перезапускают; иначе можно получить прежнюю тишину с меньшим количеством улик.
Тому, кто обслуживает программу, я бы предложил начать с getMe. Telegram описывает этот метод как проверку токена; в ответ приходят базовые сведения о боте. Их стоит сопоставить с тем аккаунтом, который сейчас проверяют. Успешный ответ означает, что этот запрос с этим токеном прошёл, а не что сценарий записи здоров и база доступна. Выдавать справку о знакомстве за справку о трудоспособности — занятный административный жанр, но программам он не помогает.
Дальше надо понять, как входящее событие попадает к исполнителю. Здесь есть развилка. При webhook Telegram отправляет его на заданный адрес сервера. При long polling программа сама запрашивает события методом getUpdates. В документации эти способы названы взаимоисключающими. Поэтому совет запустить ещё один получатель «просто посмотреть сообщения» я бы отложил до выяснения действующей схемы. Диагностика не должна незаметно становиться переделкой доставки.
Состояние webhook можно запросить через getWebhookInfo. У него есть адрес доставки, число ожидающих обновлений pending_update_count и сведения о последней ошибке. Специалисту я предложил бы сохранить ответ до теста и после него, чтобы сравнивать состояние одной и той же доставки, а перед пересылкой убрать секретные части адреса — вместе с токеном, если он там оказался. Пустой url сам по себе не авария — так выглядит и работа через getUpdates. Заполненный адрес тоже не свидетельство здоровья — важно, куда он ведёт и что происходит при доставке.
Если очередь растёт, а рядом появляется свежая ошибка, первым предметом проверки становится путь к серверу. Но слово «свежая» здесь дороже грозного текста ошибки. Поля last_error_message и last_error_date относятся к последней неудачной доставке; старую запись нельзя автоматически объявлять объяснением нынешнего молчания. В FAQ отдельно указаны действительный SSL-сертификат и отсутствие поддержки перенаправлений. Я бы предложил проверить именно настроенный адрес, а не довольствоваться тем, что главная страница сайта открывается в браузере.
С long polling порядок другой. Я бы попросил проверить, запущена ли программа-получатель и что в её журнале во время тестового сообщения. В описании getUpdates есть существенная оговорка: при установленном webhook этот метод не работает. Там же определён offset — граница подтверждения полученных событий. Подставлять в него случайные числа ради оживления бота не стоит. Можно подтвердить обновления раньше, чем программа успела их обработать, и затем искать исчезнувшие сообщения уже без прежней очереди.
Теперь неприятный поворот. Доставка могла пройти нормально.
Отсутствие ожидающих обновлений ещё не говорит, что пользователь получил ответ. Я бы предложил сопоставить одно тестовое событие с журналом обработчика: программа его приняла, выбрала нужную ветку, дошла до отправки? Если остановка произошла при обращении к базе или внешнему сервису, обсуждать замену webhook уже поздно по маршруту и мимо причины. Это гипотезы для проверки по журналу, а не диагноз любому молчащему боту.
У кнопок есть дополнительная ловушка. Обычное входящее сообщение и запрос от callback-кнопки обозначены в объекте Update разными полями — message и callback_query. Параметр allowed_updates позволяет ограничить типы получаемых событий; в getUpdates и setWebhook прежняя настройка сохраняется, если параметр не передать. Если команда отвечает, а такая кнопка молчит, я бы предложил проверить фильтр доставки и обработчик этой кнопки. Само по себе работающее /start не оправдывает всю остальную программу.
Последняя граница — отправка ответа. Я бы попросил найти результат конкретного исходящего запроса, если приложение отправляет его отдельно, и сопоставить его с тем же тестом. При ограничении частоты Telegram может вернуть retry_after — число секунд до повторной попытки, как указано в ResponseParameters. Это основание предложить проверить ожидание и повтор, а не безостановочно стучать тем же запросом. Для ответа, встроенного прямо в HTTP-ответ webhook, FAQ оговаривает другое ограничение: результат такого вызова получить нельзя. Способ отправки тоже придётся выяснить.
Меньше всего мне нравится ремонт с уничтожением свидетельств. Параметр drop_pending_updates в setWebhook прямо означает сброс ожидающих обновлений. Я бы не использовал его как кнопку общего оздоровления. Удалять webhook без выяснения схемы, стирать базу или разворачивать пустой проект вместо прежнего — тоже плохие первые предложения. У ещё не полученных обновлений и без этого есть предел хранения в Telegram, не больше 24 часов; история чата и сохранённые данные приложения — отдельные вещи.
Для обращения к специалисту я предлагаю небольшой технический довесок. Передать время теста, ожидаемый ответ, последнее работающее действие и очищенный от секретов фрагмент ошибки. Если обращаться ко мне, начать можно с этих сведений, без публичной пересылки токена и клиентских данных. После исправления я бы предложил повторить тот же безопасный сценарий до видимого ответа в Telegram. У аватарки в этой проверке выходной.