Waarom de Twitch-bot berichten van moderators overslaat

Bepaal eerst in welke fase het bericht verdwijnt

Controleer of de bot gewone berichten in hetzelfde kanaal ontvangt. Als er in de logs noch kijkers noch moderators staan, ligt het probleem meestal bij de autorisatie, de verbinding met de chat of de kanaalnaam. Als kijkers wel zichtbaar zijn en de berichten van de moderator ontbreken, zoek de oorzaak dan in het rollenfilter, de IRC-tags of de EventSub-subscriptie.

Kijk niet alleen naar het antwoord van de bot in de chat, maar ook naar het logboek van inkomende gebeurtenissen. Een bericht kan de applicatie bereiken, maar het commando niet starten door een prefix, cooldown, stopwoord, negeerlijst of rechtencontrole. Stuur voor een test dezelfde korte zin van een kijker en van een moderator, en daarna hetzelfde commando.

Controleer het kanaal, het botaccount en de IRC-verbinding

Zorg ervoor dat de bot precies in het juiste kanaal is ingelogd en met het account dat de chat moet lezen. Na het hernoemen van een kanaal, het wijzigen van een login of het wisselen tussen een test- en productieomgeving kan de applicatie online blijven, maar een andere chat volgen.

In het verbindingslog moeten een geslaagde autorisatie, de nick van de bot en het commando om het kanaal binnen te gaan zichtbaar zijn. Controleer na een verbindingsverbreking niet alleen de pogingen tot opnieuw verbinden, maar ook of er daadwerkelijk een nieuwe geslaagde login is. Automatisch opnieuw verbinden zonder een fout te loggen verbergt een verlopen token, een onjuist OAuth-wachtwoord of een fout in de kanaalnaam.

Controleer het OAuth-token en de leesrechten

Het token moet toebehoren aan het account waarmee de bot de chat leest. Verwar het niet met het token van de streamer: de rechten van de kanaaleigenaar worden niet overgedragen aan een afzonderlijk botaccount. Voor het lezen van berichten via IRC is de scope chat:read nodig.

Als berichten via EventSub worden ontvangen, is voor de chatgebeurtenis een gebruikerstoken met het recht user:read:chat nodig. Afhankelijk van het autorisatieschema en van wie de subscriptie aanmaakt, kunnen ook rechten voor toegang van de bot tot het kanaal nodig zijn, waaronder channel:bot. Voeg scopes niet willekeurig toe: stem ze af op het huidige subscriptieschema en op het account namens wie de subscriptie wordt aangemaakt.

De geldigheid van een gebruikerstoken en de lijst met verleende rechten kun je controleren met een verzoek:

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

Controleer in het antwoord de login, de gebruikers-id, de geldigheidsduur en de array scopes. Als chat:read of user:read:chat ontbreekt, is opnieuw autoriseren met de juiste set rechten nodig. Het nadeel van deze oplossing is dat oude tokens en opgeslagen sessies in de configuratie van de bot moeten worden vervangen, anders blijft hij met de oude rechten werken.

Scheid de diagnose van IRC en EventSub

IRC en EventSub leveren berichten via verschillende wegen af. IRC stuurt de chatstream over een permanente verbinding: in het ruwe log moet je de regel PRIVMSG van de moderator vinden. EventSub levert de gebeurtenis channel.chat.message via een aangemaakte API-subscriptie: hier controleer je de status, de condition en het transport van de aflevering.

Als de bot beide bronnen gebruikt, log dan de bron van elke gebeurtenis. Anders kan één bericht twee keer worden verwerkt, terwijl een storing in één transport onopgemerkt blijft. Als alleen EventSub wordt gebruikt, geldt het ontbreken van een IRC-verbinding niet als fout. Het nadeel van het EventSub-schema is dat de bot bij een onjuiste of uitgeschakelde subscriptie helemaal geen berichten ziet, zelfs niet met een werkend token.

Controleer de EventSub-subscriptie op chatberichten

Zoek in de lijst met subscripties de gebeurtenis channel.chat.message. De vermelding moet een actieve status hebben. Controleer in de condition broadcaster_user_id — de id van het streamerkanaal — en user_id van de gebruiker die de gebeurtenissen ontvangt. Een fout in een van deze id's ziet er vaak uit als het selectief ontbreken van berichten.

Vraag de lijst met subscripties op via GET /helix/eventsub/subscriptions. Controleer in het antwoord type, status, condition en transport. De status enabled betekent dat de subscriptie actief is; meldingen over een mislukte aflevering, een verwijderde vermelding of een ander kanaal wijzen op de oorzaak. Gebruik voor dit verzoek het token en de Client ID van de applicatie die de subscriptie heeft aangemaakt.

Vertrouw niet alleen op de aanwezigheid van een vermelding in het paneel of de database van de bot. De subscriptie kan zijn aangemaakt voor een testkanaal, verwijderd na een afleveringsfout of bij een andere applicatie horen. Het nadeel van controle via de API is dat deze de configuratie van de subscriptie toont, maar niet de filterlogica binnen de handler zelf verklaart.

Schakel IRC-tags in en controleer de rol van de auteur

Als de rechtencontrole op IRC is gebaseerd, moet de client de capability twitch.tv/tags aanvragen. Zonder tags kan de bot wel de tekst en de nick van de auteur ontvangen, maar niet de velden mod en badges zien. In dat geval komen gewone commando's binnen, maar geven moderatorregels een onterechte weigering.

Zoek in het ruwe bericht van de moderator naar mod=1 en badges=moderator/1. Het veld user-type kan ontbreken, leeg zijn of niet overeenkomen met de actuele rol, dus gebruik het niet als enige kenmerk. De parser moet lege tagwaarden en geëscaleerde tekens correct verwerken; het nadeel van de IRC-aanpak is juist dat dit formaat zelf moet worden geparseerd.

Als mod=1 ontbreekt, controleer dan eerst of de capability voor tags daadwerkelijk door de server is bevestigd en niet alleen door de client is verzonden. Controleer daarna badges. De waarde moderator/1 betekent moderator, broadcaster/1 betekent kanaaleigenaar. Een VIP heeft meestal de badge vip/1, maar een VIP wordt niet automatisch moderator. De streamer en VIP's kun je niet op basis van nick, kleur of display-name als moderator beschouwen: bepaal de rol aan de hand van badges en afzonderlijke toegangsregels.

Controleer de rolregels in de code en instellingen

Vergelijk ruwe gebeurtenissen van een kijker, VIP, moderator en kanaaleigenaar met dezelfde tekst. Als de gebeurtenis van de moderator de applicatie bereikt, maar de handler hem heeft overgeslagen, zit de fout na de ontvangst: in de rolcontrole, de zwarte lijst, de antispam of de commandoroutering.

• Zet logins op dezelfde letterkast voordat je ze vergelijkt.
• Controleer mod=1 en de badge moderator, niet één vaste set tags.
• Bepaal afzonderlijk de rechten voor broadcaster, moderator, vip en het account van de bot zelf.
• Controleer of de moderator op de negeerlijst, banlijst of lijst met verboden gebruikers staat.
• Bekijk de volgorde van de voorwaarden: antispam of stopwoorden kunnen eerder afgaan dan de rolcontrole.
• Zorg ervoor dat het commando niet wordt geblokkeerd door een regel voor berichten met een vermelding, een link of herhaalde tekst.

Een handmatige lijst met nicks is alleen geschikt voor een korte diagnose. Het nadeel is dat deze verouderd raakt na een wisseling van moderators, het hernoemen van een account of een wijziging van rollen in het kanaal.

Sluit het commandformaat, limieten en verborgen negeren uit

De bot kan een bericht zien en bewust niet antwoorden. Controleer de cooldown van het commando, de limiet op berichten van één gebruiker, de bescherming tegen herhalingen, het emojifilter en de stopwoorden. Moderators sturen commando's vaak snel en kunnen net als kijkers door de antispam worden geraakt.

Test afzonderlijk een gewone zin en een commando met een prefix. Als de zin wel in het log staat, maar het commando niet tot het verwerkingsresultaat komt, controleer dan de prefix, de toetsenbordindeling, spaties, onzichtbare tekens en argumenten. Commando's met een slash en moderatieacties komen niet altijd binnen als gewone tekst die de handler verwacht.

Log de reden van de beslissing per bericht

Sla voor de diagnose de tijd, de bron van de gebeurtenis, het kanaal, de id van de auteur, het berichttype, de tags en het verwerkingsresultaat op. De tekst kan worden gemaskeerd als die niet nodig is om de fout te vinden. In het log moet een concrete reden staan: bericht niet ontvangen, rol niet herkend, prefix niet doorgekomen, cooldown actief, gebruiker genegeerd of EventSub-subscriptie uitgeschakeld.

Schrijf geen OAuth-tokens, applicatiegeheimen, webhookadressen en volledige autorisatieheaders in gewone logs. Deze gegevens zijn handig bij het debuggen, maar een lek kan toegang geven tot de bot en de instellingen van de applicatie.

Diagnosechecklist in volgorde

1. Stuur dezelfde zin en hetzelfde commando van een kijker en van een moderator.
2. Controleer het ruwe log en bepaal of het bericht via IRC, EventSub of beide bronnen is binnengekomen.
3. Als IRC geen berichten ontvangt, controleer dan het botaccount, de kanaalnaam, het token en een geslaagde login in de chat.
4. Als het IRC-bericht wel is binnengekomen, zorg dan dat tags zijn ingeschakeld en controleer daarna mod=1 en badges=moderator/1.
5. Als mod=1 ontbreekt, controleer dan de bevestiging van twitch.tv/tags en onderscheid moderator/1, vip/1 en broadcaster/1.
6. Controleer het token via validate: voor IRC is chat:read nodig, voor EventSub-berichten user:read:chat.
7. Controleer bij gebruik van EventSub channel.chat.message, de status enabled, de condition en het transport in de lijst met subscripties.
8. Vergelijk de verwerking van rollen, de negeerlijst, antispam, prefix, cooldown en stopwoorden.
9. Voeg aan het log een expliciete reden toe waarom elk bericht is geaccepteerd, genegeerd of afgewezen.