Telegram-бот отправляет ответ дважды: где искать сбой в обработке событий

Установите, что именно дублируется

Сравните время, текст и технический идентификатор двух исходящих сообщений. Они полностью одинаковы или второе слегка перефразировано? Первый вариант чаще указывает на повтор отправки готового результата; второй — на повторный вызов модели. Проверьте, возникла ли в CRM одна карточка или тоже две. Это поможет найти этап, на котором цепочка разветвилась.

Запишите `update_id` входящего события, идентификатор чата, время получения, статус обработки и идентификаторы исходящих сообщений. Личные данные в логах ограничьте. Для воспроизведения достаточно тестового чата и искусственного замедления ответа обработчика.

Проверьте режим получения событий

Telegram Bot API описывает два маршрута: `getUpdates` и webhook. Их нельзя использовать одновременно как независимые рабочие способы для одного бота. При webhook Telegram повторяет доставку, если сервер не подтвердил запрос успешным ответом. При `getUpdates` нужно корректно сдвигать `offset`. Поэтому обработчик обязан понимать повтор как штатную возможность, а не как уникальное новое сообщение.

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

Сделайте операцию идемпотентной

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

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

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

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

Ожидаемый результат: клиент видит один ответ или явную передачу человеку, а журнал показывает один итог по каждому входящему событию. В FAQ Telegram для ботов разбираются повторные обновления и режимы получения. Эти правила стоит держать рядом с тестами интеграции, потому что проблема вернётся при смене способа доставки.

Что делать с уже получившими дубли клиентами

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

Почему быстрый ответ серверу важен

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

Когда дубли появляются только после ручной передачи

Проверьте состояние диалога в момент подключения оператора. Автоматический ответ мог уже стоять в очереди, пока человек писал свой. При передаче нужно отменять или пересматривать неподтверждённые автоматические сообщения. В тесте попросите оператора войти в разговор непосредственно перед готовностью ответа ИИ. Ожидаемый результат — клиент получает один согласованный ответ, а в журнале видно, почему второй был остановлен.

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

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

Обработка ответа, который уже ушёл

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

Проверьте это в тестовой среде искусственным прерыванием процесса именно после отправки, а не только до неё.

Когда бот перестал отвечать совсем, используйте проверку webhook и очереди.