Qué hacer si el chatbot responde dos veces en directo

Primero determine el tipo de duplicado

Dos respuestas idénticas seguidas no son una sola avería, sino al menos dos distintas. Primer caso: el bot recibió un solo evento, pero dos veces. Segundo: el evento llegó una vez, pero lo envió dos veces. Se solucionan de forma diferente, así que no empiece corrigiendo el código: empiece por los logs.

Abra el registro del bot y localice el momento del duplicado. Después fíjese en dos campos: el identificador del evento y la hora de recepción.

• Dos solicitudes con el mismo event_id (o message_id, notification_id — el nombre depende de la plataforma) y una diferencia de milisegundos: es una redelivery del mismo evento. Busque la deduplicación.
• Dos solicitudes con identificadores distintos: hay dos handlers realmente suscritos al canal. Busque la segunda suscripción.

Si no hay logs en absoluto, empiece por los paneles de las plataformas: allí se ve quién está suscrito a los eventos del canal.

Cómo se ve una doble suscripción en los paneles

Las plataformas no muestran «bot conectado dos veces» en una sola línea. Los indicios están repartidos por distintas secciones.

Twitch

Revise la sección Connections en la configuración de la cuenta: allí está la lista de aplicaciones conectadas. Un mismo bot puede estar autorizado tanto como aplicación del canal como aplicación de su cuenta personal. Además, las suscripciones de EventSub viven por separado: la aplicación puede mantener una suscripción activa a channel.chat.message después de que usted haya desconectado la integración en el panel. Una segunda instancia del bot, ejecutada localmente, también recibe eventos igual que la que está en producción.

YouTube

Aquí el culpable suele ser no el bot en sí, sino el acceso al chat: el bot está conectado a la transmisión tanto como moderador como cuenta participante aparte. Revise la lista de moderadores y la lista de aplicaciones autorizadas del canal. Aparte: si el bot funciona a través de varios proyectos de Google Cloud, las claves pueden ir por dos rutas distintas.

Discord

El caso más evidente: dos aplicaciones con el mismo token en un mismo servidor. Ambas ven el mensaje en el canal y ambas responden. Revise la lista de bots del servidor y asegúrese de que no haya un segundo webhook con el mismo nombre conectado al canal.

La desventaja de este camino es que hace falta acceso no solo al bot, sino también a los paneles del canal. Si varias personas gestionan el canal, puede que otra haya levantado la segunda instancia y usted no lo sepa.

Repetición del webhook: por qué el evento llega dos veces

El servicio externo entrega el webhook y espera confirmación. Si no la recibe en el tiempo previsto, lo envía otra vez. La segunda solicitud lleva el mismo evento, pero el bot la interpreta como nueva y responde de nuevo. Esto ocurre ante cualquier bloqueo del servidor: cuanto mayor es la carga, más a menudo.

Se soluciona con deduplicación en el lado del bot. Hace falta una clave que sea igual para todas las copias de un mismo evento y única para eventos distintos. La clave se toma del cuerpo de la solicitud o de las cabeceras: depende de la API, pero el esquema es el mismo.

Ejemplo de clave de deduplicación

Imagine un webhook sobre una nueva donación. En el cuerpo llega un objeto con el campo id: un número único de transacción que no cambia en la redelivery. La lógica es esta:

1. Al recibir la solicitud, extraiga el id del cuerpo.
2. Compruebe en el almacén (Redis, una tabla en la base de datos) si ya apareció en las últimas, digamos, veinticuatro horas.
3. Si ya apareció, responda al servicio «recibido» y no envíe nada al chat.
4. Si no, guárdelo y procéselo como de costumbre.

La clave debe provenir del evento, no generarla usted: si genera la suya, dos entregas de un mismo evento tendrán claves distintas y la deduplicación no funcionará. Algunas plataformas ofrecen una cabecera ya lista con el identificador de entrega: en ese caso, úsela, es más fiable. La desventaja del enfoque es que hace falta un almacén y una política de limpieza; si no, la base de claves crece sin límite.

Si el duplicado viene de dos fuentes distintas

Un caso aparte es cuando el evento no se repite, sino que realmente llega de dos lugares. El clásico: el bot responde a un comando tanto en el chat como en el reenvío entre plataformas a través de un puente. O la respuesta automática está configurada con dos disparadores que se activan con la misma frase.

Estos duplicados se distinguen de la repetición del webhook por los logs: las solicitudes tienen orígenes distintos (plataformas distintas, handlers distintos), pero un mismo evento semántico. Busque la intersección de disparadores y desactive uno de ellos. Para el puente: no reenvíe de vuelta los mensajes del propio bot.

Comprobación antes del directo

1. Envíe un comando de prueba y vea cuántas respuestas llegaron.
2. Desconecte todas las integraciones menos una, repita.
3. Vaya activándolas de una en una hasta que vuelva el duplicado: así encontrará al culpable.
4. Compare en los logs el identificador del evento en ambas respuestas: si es igual, es redelivery; si es distinto, es una segunda suscripción.

Si no encuentra la causa, desactive la respuesta automática al evento problemático y escriba al soporte del servicio con los logs y la hora de la repetición. Mientras espera, gestione el chat manualmente: mejor perder la automatización una noche que llenar el directo de frases idénticas.