Що робити, якщо чат-бот відповідає в ефірі двічі

Спочатку визначте тип дублю

Дві однакові відповіді поспіль — це не одна поломка, а щонайменше дві різні. Перший випадок: бот отримав одну подію, але двічі. Другий: подія прийшла одна, а надіслав він двічі. Лікуються вони по-різному, тому не починайте з правки коду — почніть з логів.

Відкрийте журнал бота й знайдіть момент дублю. Далі дивіться на два поля: ідентифікатор події та час отримання.

• Два запити з одним 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. Звірте за логами ідентифікатор події в обох відповідях: однаковий — повтор доставки, різний — друга підписка.

Якщо причину не знайти, вимкніть автовідповідь на проблемну подію й напишіть у підтримку сервісу з логами й часом повтору. Поки чекаєте — ведіть чат вручну: краще втратити автоматизацію на вечір, ніж залити ефір однаковими фразами.