Por qué el bot de Twitch omite los mensajes de los moderadores

Primero determine en qué etapa se pierde el mensaje

Compruebe si el bot recibe mensajes normales en el mismo canal. Si en los registros no aparecen ni espectadores ni moderadores, el problema suele estar en la autorización, la conexión al chat o el nombre del canal. Si los espectadores son visibles y las intervenciones del moderador no aparecen, busque la causa en el filtro de roles, las etiquetas IRC o la suscripción de EventSub.

No mire solo la respuesta del bot en el chat, sino el registro de eventos entrantes. El mensaje puede llegar a la aplicación pero no activar el comando debido al prefijo, el tiempo de espera, las palabras bloqueadas, la lista de ignorados o la comprobación de permisos. Para la prueba, envíe desde un espectador y desde un moderador la misma frase corta y luego el mismo comando.

Compruebe el canal, la cuenta del bot y la conexión IRC

Asegúrese de que el bot haya entrado exactamente en el canal correcto y con la cuenta que debe leer el chat. Tras renombrar el canal, cambiar el inicio de sesión o alternar entre el entorno de pruebas y el de producción, la aplicación puede seguir en línea pero estar escuchando otro chat.

En el registro de conexión deben verse la autorización correcta, el nick del bot y el comando de entrada al canal. Tras una desconexión, compruebe no solo los intentos de reconexión, sino también el hecho de una nueva entrada correcta. La reconexión automática sin registrar el error oculta un token caducado, una contraseña OAuth incorrecta o un error en el nombre del canal.

Compruebe el token OAuth y los permisos de lectura

El token debe pertenecer a la cuenta con la que el bot lee el chat. No lo confunda con el token del streamer: los permisos del propietario del canal no se transfieren a una cuenta de bot independiente. Para leer mensajes mediante IRC se necesita el scope chat:read.

Si los mensajes se reciben mediante EventSub, para el evento de chat se necesita un token de usuario con el permiso user:read:chat. Según el esquema de autorización y quién cree la suscripción, también pueden requerirse permisos para que el bot acceda al canal, incluido channel:bot. No añada scopes al azar: compárelos con el esquema de suscripción actual y con la cuenta en cuyo nombre se crea.

Puede comprobar la validez del token de usuario y la lista de permisos concedidos con la solicitud:

curl -H "Authorization: OAuth $BOT_OAUTH_TOKEN" https://id.twitch.tv/oauth2/validate

En la respuesta compruebe el login, el identificador de usuario, la fecha de caducidad y el array de scopes. Si falta chat:read o user:read:chat, será necesario volver a autorizar con el conjunto de permisos adecuado. La desventaja de esta solución es que los tokens antiguos y las sesiones guardadas deben reemplazarse en la configuración del bot; de lo contrario, seguirá funcionando con los permisos anteriores.

Separe el diagnóstico de IRC y EventSub

IRC y EventSub entregan los mensajes por vías distintas. IRC transmite el flujo del chat mediante una conexión permanente: en el registro sin procesar hay que encontrar la línea PRIVMSG del moderador. EventSub entrega el evento channel.chat.message mediante una suscripción de API creada: aquí se comprueban su estado, condition y transporte de entrega.

Si el bot usa ambas fuentes, registre en el log la fuente de cada evento. De lo contrario, un mismo mensaje puede procesarse dos veces y el fallo de un transporte pasará desapercibido. Si solo se usa EventSub, la ausencia de conexión IRC no se considera un error. La desventaja del esquema EventSub es que, con una suscripción incorrecta o desactivada, el bot no verá los mensajes en absoluto, incluso con un token válido.

Compruebe la suscripción de EventSub a los mensajes del chat

En la lista de suscripciones busque el evento channel.chat.message. La entrada debe tener un estado activo. En condition compruebe broadcaster_user_id —el identificador del canal del streamer— y user_id del usuario que recibe los eventos. Un error en cualquiera de estos ID suele manifestarse como una ausencia selectiva de mensajes.

Solicite la lista de suscripciones mediante GET /helix/eventsub/subscriptions. En la respuesta compruebe type, status, condition y transport. El estado enabled significa que la suscripción está activa; las notificaciones de fallo de entrega, una entrada eliminada u otro canal indicarán la causa. Para esta solicitud use el token y el Client ID de la aplicación que creó la suscripción.

No se base solo en la presencia de una entrada en el panel o en la base de datos del bot. La suscripción pudo crearse para un canal de prueba, eliminarse tras un error de entrega o pertenecer a otra aplicación. La desventaja de la comprobación mediante API es que muestra la configuración de la suscripción, pero no explica la lógica de filtrado dentro del propio controlador.

Active las etiquetas IRC y compruebe el rol del autor

Si la comprobación de permisos se basa en IRC, el cliente debe solicitar la capability twitch.tv/tags. Sin las etiquetas, el bot puede recibir el texto y el nick del autor, pero no ver los campos mod y badges. En ese caso, los comandos normales llegan, pero las reglas para moderadores dan un rechazo falso.

En el mensaje sin procesar del moderador busque mod=1 y badges=moderator/1. El campo user-type puede faltar, estar vacío o no corresponder al rol actual, así que no lo use como único indicio. El parser debe procesar correctamente los valores vacíos de las etiquetas y los caracteres escapados; la desventaja del enfoque IRC radica precisamente en la necesidad de analizar este formato por cuenta propia.

Si no hay mod=1, primero asegúrese de que la capability para las etiquetas realmente haya sido confirmada por el servidor, y no solo enviada por el cliente. Luego compruebe badges. El valor moderator/1 significa moderador, broadcaster/1 — propietario del canal. El VIP normalmente tiene la badge vip/1, pero un VIP no se convierte automáticamente en moderador. No conviene considerar al streamer y al VIP como moderadores por el nick, el color o el display-name: determine el rol por las badges y por reglas de acceso específicas.

Compruebe las reglas de roles en el código y en la configuración

Compare los eventos sin procesar de un espectador, un VIP, un moderador y el propietario del canal con el mismo texto. Si el evento del moderador llegó a la aplicación pero el controlador lo omitió, el error está después de la recepción: en la comprobación del rol, la lista negra, el antispam o el enrutamiento de comandos.

• Normalice los logins a un mismo formato de mayúsculas y minúsculas antes de comparar.
• Compruebe mod=1 y la badge moderator, y no un único conjunto fijo de etiquetas.
• Defina por separado los permisos para broadcaster, moderator, vip y la cuenta del propio bot.
• Compruebe si el moderador acabó en la lista de ignorados, la lista de baneados o la lista de usuarios prohibidos.
• Revise el orden de las condiciones: el antispam o las palabras bloqueadas pueden activarse antes de la comprobación del rol.
• Asegúrese de que el comando no se bloquee por una regla para mensajes con mención, enlace o texto repetido.

Una lista manual de nicks solo sirve para un diagnóstico breve. Su desventaja es que queda obsoleta tras un cambio de moderadores, el renombrado de una cuenta o un cambio de roles en el canal.

Descarte el formato del comando, los límites y el ignorado oculto

El bot puede ver el mensaje y no responder deliberadamente. Compruebe el tiempo de espera del comando, el límite de mensajes de un mismo usuario, la protección contra repeticiones, el filtro de emojis y las palabras bloqueadas. Los moderadores suelen enviar comandos rápidamente y pueden caer en el antispam igual que los espectadores.

Pruebe por separado una frase normal y un comando con prefijo. Si la frase aparece en el log pero el comando no llega al resultado del procesamiento, compruebe el prefijo, la distribución del teclado, los espacios, los caracteres invisibles y los argumentos. Los comandos con barra y las acciones de moderación no siempre llegan como texto normal que espera el controlador.

Registre el motivo de la decisión para cada mensaje

Para el diagnóstico guarde la hora, la fuente del evento, el canal, el ID del autor, el tipo de mensaje, las etiquetas y el resultado del procesamiento. El texto puede enmascararse si no es necesario para localizar el error. En el log debe figurar un motivo concreto: mensaje no recibido, rol no reconocido, prefijo no válido, tiempo de espera activado, usuario en la lista de ignorados o suscripción de EventSub desactivada.

No registre en los logs habituales tokens OAuth, el secreto de la aplicación, las direcciones de webhooks ni las cabeceras de autorización completas. Estos datos son útiles durante la depuración, pero su filtración puede abrir acceso al bot y a la configuración de la aplicación.

Lista de comprobación del diagnóstico en orden

1. Envíe la misma frase y el mismo comando desde un espectador y desde un moderador.
2. Compruebe el log sin procesar y determine si el mensaje llegó por IRC, por EventSub o por ambas fuentes.
3. Si IRC no recibe mensajes, verifique la cuenta del bot, el nombre del canal, el token y la entrada correcta al chat.
4. Si el mensaje de IRC llegó, asegúrese de que las etiquetas estén activadas y luego compruebe mod=1 y badges=moderator/1.
5. Si falta mod=1, compruebe la confirmación de twitch.tv/tags y distinga moderator/1, vip/1 y broadcaster/1.
6. Compruebe el token mediante validate: para IRC se necesita chat:read; para los mensajes de EventSub, user:read:chat.
7. Si se trabaja mediante EventSub, compruebe channel.chat.message, el estado enabled, condition y transport en la lista de suscripciones.
8. Compare el procesamiento de roles, la lista de ignorados, el antispam, el prefijo, el tiempo de espera y las palabras bloqueadas.
9. Añada al log el motivo explícito por el que cada mensaje se acepta, se ignora o se rechaza.