What to do when the chatbot replies twice on stream

First, determine the type of duplicate

Two identical replies in a row are not one single failure but at least two different ones. First case: the bot received one event, but twice. Second: one event arrived, but it sent it twice. They are fixed differently, so don't start by editing code — start with the logs.

Open the bot log and find the moment of the duplicate. Then look at two fields: the event identifier and the time received.

• Two requests with the same event_id (or message_id, notification_id — the name depends on the platform) and a difference of milliseconds — this is a redelivery of one event. Look for deduplication.
• Two requests with different identifiers — two handlers are actually subscribed to the channel. Look for the second subscription.

If there are no logs at all, start with the platform dashboards: there you can see who is subscribed to the channel's events.

What a duplicate subscription looks like in the dashboards

Platforms don't show "bot connected twice" in a single line. The signs are scattered across different sections.

Twitch

Check the Connections section in your account settings — there's a list of connected applications. The same bot can be authorized both as a channel application and as an application of your personal account. Plus, EventSub subscriptions live separately: an application can hold an active subscription to channel.chat.message after you've disabled the integration in the dashboard. A second instance of the bot running locally also receives events alongside the working one.

YouTube

Here it's more often not the bot itself but chat access that's to blame: the bot is connected to the stream both as a moderator and as a separate participant account. Check the moderator list and the list of authorized applications for the channel. Separately — if the bot runs through several Google Cloud projects, the keys may travel along two different paths.

Discord

The most obvious case: two applications with the same token on one server. Both see the message in the channel and both reply to it. Check the list of bots on the server and make sure a second webhook with the same name isn't connected to the channel.

The downside of this path is that you need access not only to the bot but also to the channel dashboards. If several people run the channel, someone else may have spun up the second instance, and you don't know about it.

Webhook retry: why an event arrives twice

An external service delivers a webhook and waits for confirmation. If it doesn't get one within the allotted time, it sends it again. The second request carries the same event, but the bot treats it as new and replies again. This happens with any server hiccup: the more load, the more often.

It's fixed with deduplication on the bot side. You need a key that is the same for all copies of one event and unique for different ones. The key is taken from the request body or headers — it depends on the API, but the scheme is the same.

Example of a deduplication key

Imagine a webhook about a new donation. The body contains an object with an id field — a unique transaction number that doesn't change on redelivery. The logic is:

1. When a request arrives, pull the id from the body.
2. Check in storage (Redis, a database table) whether it has appeared in, say, the last 24 hours.
3. If it has — reply "accepted" to the service and send nothing to the chat.
4. If not — record it and process as usual.

The key must come from the event itself, not be generated by you: if you generate your own, two deliveries of one event will get different keys, and deduplication won't work. Some platforms provide a ready-made header with a delivery identifier — then use it, it's more reliable. The downside of the approach is that you need storage and a cleanup policy, otherwise the key database grows without limit.

If the duplicate came from two different sources

A separate story is when an event isn't repeated but actually comes from two places. The classic: the bot replies to a command both in chat and in a cross-platform relay through a bridge. Or an auto-reply is set to two triggers that fire on the same phrase.

Such duplicates differ from a webhook retry in the logs: the requests have different sources (different platforms, different handlers) but one meaningful event. Look for overlapping triggers and disable one of them. For the bridge — don't relay the bot's own messages back.

Check before going live

1. Send a test command and see how many replies came back.
2. Disable all integrations except one, repeat.
3. Enable them one by one until the duplicate returns — that's how you'll find the culprit.
4. Compare the event identifier of both replies in the logs: the same — redelivery, different — a second subscription.

If you can't find the cause, disable the auto-reply for the problematic event and write to the service's support with the logs and the time of the repeat. While you wait — run the chat manually: better to lose automation for an evening than to flood the stream with identical phrases.