De ce botul Twitch ignoră mesajele moderatorilor

Mai întâi stabiliți în ce etapă dispare mesajul

Verificați dacă botul primește mesaje obișnuite în același canal. Dacă în loguri nu apar nici spectatori, nici moderatori, problema este de obicei în autorizare, conexiunea la chat sau numele canalului. Dacă spectatorii sunt vizibili, iar replicile moderatorului lipsesc, căutați cauza în filtrul de roluri, etichetele IRC sau abonamentul EventSub.

Uitați-vă nu doar la răspunsul botului în chat, ci la jurnalul evenimentelor primite. Mesajul poate ajunge la aplicație, dar să nu declanșeze comanda din cauza prefixului, cooldown-ului, cuvintelor interzise, listei de ignorare sau verificării permisiunilor. Pentru test, trimiteți de la un spectator și de la un moderator aceeași frază scurtă, apoi aceeași comandă.

Verificați canalul, contul botului și conexiunea IRC

Asigurați-vă că botul a intrat exact în canalul dorit și sub contul care trebuie să citească chatul. După redenumirea canalului, schimbarea login-ului sau comutarea între mediul de test și cel de producție, aplicația poate rămâne online, dar să asculte alt chat.

În logul conexiunii trebuie să fie vizibile autorizarea reușită, nick-ul botului și comanda de intrare în canal. După întreruperea conexiunii, verificați nu doar încercările de reconectare, ci și faptul unei noi intrări reușite. Reconectarea automată fără înregistrarea erorii ascunde un token expirat, o parolă OAuth greșită sau o eroare în numele canalului.

Verificați tokenul OAuth și permisiunile de citire

Tokenul trebuie să aparțină contului prin care botul citește chatul. Nu îl confundați cu tokenul streamerului: permisiunile proprietarului canalului nu se transmit unui cont separat de bot. Pentru citirea mesajelor prin IRC este nevoie de scope-ul chat:read.

Dacă mesajele sunt primite prin EventSub, pentru evenimentul de chat este nevoie de un token de utilizator cu permisiunea user:read:chat. În funcție de schema de autorizare și de cine creează abonamentul, pot fi necesare și permisiuni pentru accesul botului la canal, inclusiv channel:bot. Nu adăugați scope-uri la întâmplare: verificați-le cu schema actuală de abonare și cu contul în numele căruia este creată.

Valabilitatea tokenului de utilizator și lista permisiunilor acordate pot fi verificate printr-o cerere:

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

În răspuns verificați login-ul, identificatorul utilizatorului, termenul de valabilitate și matricea scopes. Dacă chat:read sau user:read:chat lipsește, va fi necesară o nouă autorizare cu setul necesar de permisiuni. Dezavantajul acestei soluții este că tokenurile vechi și sesiunile salvate trebuie înlocuite în configurația botului, altfel acesta va continua să funcționeze cu permisiunile anterioare.

Separați diagnosticarea IRC și EventSub

IRC și EventSub livrează mesajele pe căi diferite. IRC transmite fluxul chatului printr-o conexiune permanentă: în logul brut trebuie găsită linia PRIVMSG de la moderator. EventSub transmite evenimentul channel.chat.message printr-un abonament API creat: aici se verifică statusul, condition și transportul de livrare.

Dacă botul folosește ambele surse, înregistrați în log sursa fiecărui eveniment. Altfel un mesaj poate fi procesat de două ori, iar o defecțiune a unui transport va rămâne neobservată. Dacă este folosit doar EventSub, absența conexiunii IRC nu este considerată eroare. Dezavantajul schemei EventSub — cu un abonament greșit sau dezactivat, botul nu va vedea deloc mesajele, chiar și cu un token funcțional.

Verificați abonamentul EventSub pentru mesajele de chat

În lista abonamentelor găsiți evenimentul channel.chat.message. Înregistrarea trebuie să aibă un status activ. În condition verificați broadcaster_user_id — identificatorul canalului streamerului — și user_id al utilizatorului care primește evenimentele. O eroare în oricare dintre aceste ID-uri arată adesea ca o absență selectivă a mesajelor.

Solicitați lista abonamentelor prin GET /helix/eventsub/subscriptions. În răspuns verificați type, status, condition și transport. Statusul enabled înseamnă că abonamentul este activ; notificările despre eșecul livrării, înregistrarea eliminată sau un alt canal vor indica cauza. Pentru această cerere folosiți tokenul și Client ID ale aplicației care a creat abonamentul.

Nu vă bazați doar pe prezența înregistrării în panou sau în baza de date a botului. Abonamentul poate fi creat pentru un canal de test, eliminat după o eroare de livrare sau să aparțină altei aplicații. Dezavantajul verificării prin API este că arată configurația abonamentului, dar nu explică logica de filtrare din interiorul handler-ului.

Activați etichetele IRC și verificați rolul autorului

Dacă verificarea permisiunilor se bazează pe IRC, clientul trebuie să solicite capability-ul twitch.tv/tags. Fără etichete, botul poate primi textul și nick-ul autorului, dar să nu vadă câmpurile mod și badges. În acest caz comenzile obișnuite ajung, iar regulile pentru moderatori dau un refuz fals.

În mesajul brut al moderatorului căutați mod=1 și badges=moderator/1. Câmpul user-type poate lipsi, poate fi gol sau să nu corespundă rolului actual, așa că nu îl folosiți ca unic indicator. Parserul trebuie să gestioneze corect valorile goale ale etichetelor și caracterele escape-uite; dezavantajul abordării IRC constă tocmai în necesitatea de a analiza singur acest format.

Dacă mod=1 lipsește, mai întâi asigurați-vă că capability-ul pentru etichete a fost într-adevăr confirmat de server, nu doar trimis de client. Apoi verificați badges. Valoarea moderator/1 înseamnă moderator, broadcaster/1 — proprietarul canalului. VIP-ul are de obicei badge-ul vip/1, dar VIP-ul nu devine automat moderator. Streamerul și VIP-ul nu trebuie considerați moderatori după nick, culoare sau display-name: rolul se determină după badges și reguli separate de acces.

Verificați regulile de roluri în cod și în setări

Comparați evenimentele brute de la spectator, VIP, moderator și proprietarul canalului cu același text. Dacă evenimentul de la moderator a ajuns la aplicație, dar handler-ul l-a ignorat, eroarea se află după primire: în verificarea rolului, lista neagră, antispam sau rutarea comenzilor.

• Aduceți login-urile la același registru înainte de comparare.
• Verificați mod=1 și badge-ul moderator, nu un singur set fix de etichete.
• Definiți separat permisiunile pentru broadcaster, moderator, vip și contul botului însuși.
• Verificați dacă moderatorul nu a ajuns în lista de ignorare, lista de banuri sau lista de utilizatori interziși.
• Uitați-vă la ordinea condițiilor: antispam-ul sau cuvintele interzise pot acționa înainte de verificarea rolului.
• Asigurați-vă că comanda nu este blocată de o regulă pentru mesaje cu mențiune, link sau text repetat.

Lista manuală de nick-uri este potrivită doar pentru o diagnosticare scurtă. Dezavantajul ei — devine învechită după schimbarea moderatorilor, redenumirea contului sau modificarea rolurilor în canal.

Excludeți formatul comenzii, limitele și ignorarea ascunsă

Botul poate vedea mesajul și să nu răspundă intenționat. Verificați cooldown-ul comenzii, limita de mesaje de la un utilizator, protecția împotriva repetărilor, filtrul de emoji și cuvintele interzise. Moderatorii trimit adesea comenzi rapid și pot intra sub incidența antispam-ului la fel ca spectatorii.

Testați separat o frază obișnuită și o comandă cu prefix. Dacă fraza apare în log, iar comanda nu ajunge la rezultatul procesării, verificați prefixul, layout-ul, spațiile, caracterele invizibile și argumentele. Comenzile cu slash și acțiunile de moderare nu întotdeauna ajung ca text obișnuit, pe care îl așteaptă handler-ul.

Înregistrați motivul deciziei pentru fiecare mesaj

Pentru diagnosticare păstrați timpul, sursa evenimentului, canalul, ID-ul autorului, tipul mesajului, etichetele și rezultatul procesării. Textul poate fi mascat dacă nu este necesar pentru găsirea erorii. În log trebuie să existe un motiv concret: mesajul nu a fost primit, rolul nu a fost recunoscut, prefixul nu a trecut, cooldown-ul a acționat, utilizatorul este în lista de ignorare sau abonamentul EventSub este dezactivat.

Nu înregistrați în logurile obișnuite tokenuri OAuth, secretul aplicației, adresele webhook-urilor și anteturile complete de autorizare. Aceste date sunt utile la depanare, dar scurgerea lor poate deschide accesul la bot și la setările aplicației.

Listă de verificare pentru diagnosticare, în ordine

1. Trimiteți aceeași frază și aceeași comandă de la un spectator și de la un moderator.
2. Verificați logul brut și stabiliți dacă mesajul a venit prin IRC, EventSub sau ambele surse.
3. Dacă IRC nu primește mesaje, verificați contul botului, numele canalului, tokenul și intrarea reușită în chat.
4. Dacă mesajul IRC a venit, asigurați-vă că etichetele sunt activate, apoi verificați mod=1 și badges=moderator/1.
5. Dacă mod=1 lipsește, verificați confirmarea twitch.tv/tags și distingeți moderator/1, vip/1 și broadcaster/1.
6. Verificați tokenul prin validate: pentru IRC este nevoie de chat:read, pentru mesajele EventSub — de user:read:chat.
7. La lucrul prin EventSub verificați channel.chat.message, statusul enabled, condition și transport în lista abonamentelor.
8. Comparați procesarea rolurilor, lista de ignorare, antispam-ul, prefixul, cooldown-ul și cuvintele interzise.
9. Adăugați în log motivul explicit pentru care fiecare mesaj este acceptat, ignorat sau respins.