O que fazer se o chatbot responde duas vezes na live

Primeiro, determine o tipo de duplicação

Duas respostas iguais em sequência não são uma única falha, mas no mínimo duas diferentes. Primeiro caso: o bot recebeu um evento, mas duas vezes. Segundo: o evento chegou uma vez, mas ele enviou duas. Eles são corrigidos de formas diferentes, então não comece editando o código — comece pelos logs.

Abra o log do bot e encontre o momento da duplicação. Em seguida, observe dois campos: o identificador do evento e o horário de recebimento.

• Duas requisições com o mesmo event_id (ou message_id, notification_id — o nome depende da plataforma) e diferença de milissegundos — é o reenvio de um mesmo evento. Procure a deduplicação.
• Duas requisições com identificadores diferentes — há realmente dois handlers inscritos no canal. Procure a segunda assinatura.

Se não houver logs, comece pelos painéis das plataformas: lá é possível ver quem está inscrito nos eventos do canal.

Como é uma assinatura dupla nos painéis

As plataformas não mostram "bot conectado duas vezes" em uma única linha. Os indícios estão espalhados por seções diferentes.

Twitch

Verifique a seção Connections nas configurações da conta — lá está a lista de aplicativos conectados. O mesmo bot pode estar autorizado tanto como aplicativo do canal quanto como aplicativo da sua conta pessoal. Além disso, as assinaturas do EventSub ficam separadas: o aplicativo pode manter uma assinatura ativa em channel.chat.message depois que você desativou a integração no painel. Uma segunda instância do bot, rodando localmente, também recebe eventos igual à que está em produção.

YouTube

Aqui, na maioria das vezes, a culpa não é do bot em si, mas do acesso ao chat: o bot está conectado à transmissão tanto como moderador quanto como uma conta participante separada. Verifique a lista de moderadores e a lista de aplicativos autorizados do canal. Separadamente — se o bot funciona por meio de vários projetos do Google Cloud, as chaves podem passar por dois caminhos diferentes.

Discord

O caso mais evidente: dois aplicativos com o mesmo token no mesmo servidor. Ambos veem a mensagem no canal e ambos respondem a ela. Verifique a lista de bots no servidor e certifique-se de que não há um segundo webhook com o mesmo nome conectado ao canal.

A desvantagem desse caminho é que você precisa de acesso não só ao bot, mas também aos painéis do canal. Se o canal é administrado por várias pessoas, a segunda instância pode ter sido iniciada por outra pessoa, e você não sabe disso.

Reenvio de webhook: por que o evento chega duas vezes

O serviço externo entrega o webhook e aguarda a confirmação. Se não receber dentro do tempo estipulado, envia novamente. A segunda requisição carrega o mesmo evento, mas o bot a interpreta como nova e responde de novo. Isso acontece com qualquer travamento do servidor: quanto maior a carga, mais frequente.

A solução é a deduplicação do lado do bot. É preciso uma chave que seja igual para todas as cópias de um mesmo evento e única para eventos diferentes. A chave é obtida do corpo da requisição ou dos cabeçalhos — isso depende da API, mas o esquema é o mesmo.

Exemplo de chave de deduplicação

Imagine um webhook sobre uma nova doação. No corpo chega um objeto com o campo id — um número único de transação que não muda no reenvio. A lógica é esta:

1. Ao receber a requisição, extraia o id do corpo.
2. Verifique no armazenamento (Redis, tabela no banco) se ele apareceu nas últimas, digamos, 24 horas.
3. Se apareceu — responda ao serviço "recebido" e não envie nada ao chat.
4. Se não — registre e processe normalmente.

A chave deve vir do evento, e não ser gerada por você: se gerar a sua própria, duas entregas de um mesmo evento terão chaves diferentes, e a deduplicação não funcionará. Algumas plataformas fornecem um cabeçalho pronto com o identificador de entrega — nesse caso, use-o, é mais confiável. A desvantagem da abordagem é que é preciso um armazenamento e uma política de limpeza, senão a base de chaves cresce sem limite.

Se a duplicação veio de duas fontes diferentes

Um caso à parte é quando o evento não se repete, mas realmente vem de dois lugares. O clássico: o bot responde a um comando tanto no chat quanto no encaminhamento entre plataformas por meio de uma ponte. Ou a resposta automática está configurada para dois gatilhos que disparam com a mesma frase.

Essas duplicações se diferenciam do reenvio de webhook pelos logs: as requisições têm origens diferentes (plataformas diferentes, handlers diferentes), mas um único evento semântico. Procure a interseção dos gatilhos e desative um deles. Para a ponte — não reencaminhe as mensagens do próprio bot de volta.

Verificação antes da live

1. Envie um comando de teste e veja quantas respostas chegaram.
2. Desative todas as integrações, exceto uma, e repita.
3. Ative uma por uma até a duplicação voltar — assim você encontra o culpado.
4. Confira nos logs o identificador do evento nas duas respostas: igual — reenvio de entrega, diferente — segunda assinatura.

Se a causa não for encontrada, desative a resposta automática para o evento problemático e escreva para o suporte do serviço com os logs e o horário da repetição. Enquanto espera — conduza o chat manualmente: é melhor perder a automação por uma noite do que encher a live com frases iguais.