Что делать, если чат-бот отвечает в эфире дважды

Сначала определите тип дубля

Два одинаковых ответа подряд — не одна поломка, а минимум две разные. Первый случай: бот получил одно событие, но дважды. Второй: событие пришло одно, а отправил он два раза. Лечатся они по-разному, поэтому не начинайте с правки кода — начните с логов.

Откройте журнал бота и найдите момент дубля. Дальше смотрите на два поля: идентификатор события и время получения.

• Два запроса с одним event_id (или message_id, notification_id — название зависит от платформы) и разницей в миллисекунды — это повторная доставка одного события. Ищите дедупликацию.
• Два запроса с разными идентификаторами — на канал реально подписаны два обработчика. Ищите вторую подписку.

Если логов нет вообще, начните с панелей платформ: там видно, кто подписан на события канала.

Как выглядит двойная подписка в панелях

Платформы не показывают «бот подключён дважды» одной строкой. Признаки разбросаны по разным разделам.

Twitch

Проверьте раздел Connections в настройках аккаунта — там список подключённых приложений. Один и тот же бот может быть авторизован и как приложение канала, и как приложение вашего личного аккаунта. Плюс EventSub-подписки живут отдельно: приложение может держать активную подписку на channel.chat.message после того, как вы отключили интеграцию в панели. Второй экземпляр бота, запущенный локально, тоже получает события наравне с рабочим.

YouTube

Здесь чаще виноват не сам бот, а доступ к чату: бот подключён к трансляции и как модератор, и как отдельный аккаунт-участник. Смотрите список модераторов и список авторизованных приложений канала. Отдельно — если бот работает через несколько проектов Google Cloud, ключи могут ходить по двум разным путям.

Discord

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

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

Повтор вебхука: почему событие приходит дважды

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

Лечится дедупликацией на стороне бота. Нужен ключ, который одинаков для всех копий одного события и уникален для разных. Ключ берётся из тела запроса или заголовков — это зависит от API, но схема одинаковая.

Пример ключа дедупликации

Представьте вебхук о новом донате. В теле приходит объект с полем id — уникальным номером транзакции, который не меняется при повторной доставке. Логика такая:

1. При получении запроса вытащите id из тела.
2. Проверьте в хранилище (Redis, таблица в базе), встречался ли он за последние, скажем, сутки.
3. Если встречался — ответьте сервису «принято» и ничего не отправляйте в чат.
4. Если нет — запишите и обработайте как обычно.

Ключ должен быть именно из события, а не сгенерированный вами: если генерировать свой, у двух доставок одного события получатся разные ключи, и дедупликация не сработает. Некоторые платформы дают готовый заголовок с идентификатором доставки — тогда берите его, это надёжнее. Минус подхода — нужно хранилище и политика очистки, иначе база ключей растёт без предела.

Если дубль пришёл из двух разных источников

Отдельная история — когда событие не повторяется, а реально приходит из двух мест. Классика: бот отвечает на команду и в чате, и в пересылке между платформами через мост. Или автоответ настроен на два триггера, которые срабатывают на одну и ту же фразу.

Такие дубли отличаются от повтора вебхука по логам: у запросов разные источники (разные платформы, разные обработчики), но одно смысловое событие. Ищите пересечение триггеров и отключите один из них. Для моста — не пересылайте сообщения самого бота обратно.

Проверка перед эфиром

1. Отправьте тестовую команду и посмотрите, сколько ответов пришло.
2. Отключите все интеграции, кроме одной, повторите.
3. Включайте по одной, пока дубль не вернётся, — так найдёте виновника.
4. Сверьте по логам идентификатор события у обоих ответов: одинаковый — повтор доставки, разный — вторая подписка.

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