Miért hagyja ki a Twitch-bot a moderátorok üzeneteit?

Először határozza meg, melyik szakaszban tűnik el az üzenet

Ellenőrizze, hogy a bot megkapja-e a normál üzeneteket ugyanabban a csatornában. Ha a naplókban sem nézők, sem moderátorok nem jelennek meg, a probléma általában az engedélyezésben, a chatkapcsolatban vagy a csatorna nevében van. Ha a nézők láthatók, de a moderátor hozzászólásai hiányoznak, keresse az okot a szerepkörszűrőben, az IRC-tagekben vagy az EventSub-feliratkozásban.

Ne csak a bot chatválaszára figyeljen, hanem a bejövő események naplójára is. Az üzenet eljuthat az alkalmazáshoz, de a parancs nem indul el az előtag, a cooldown, a tiltott szavak, az ignorálási lista vagy a jogosultságellenőrzés miatt. Tesztként küldjön ugyanazt a rövid mondatot egy nézőtől és egy moderátortól, majd ugyanazt a parancsot is.

Ellenőrizze a csatornát, a bot fiókját és az IRC-kapcsolatot

Győződjön meg arról, hogy a bot valóban a megfelelő csatornába lépett be, és azzal a fiókkal, amelynek a chatet olvasnia kell. A csatorna átnevezése, a bejelentkezési név módosítása vagy a teszt- és éles környezet közötti váltás után az alkalmazás online maradhat, de egy másik chatet figyelhet.

A kapcsolódási naplóban láthatónak kell lennie a sikeres engedélyezésnek, a bot becenevének és a csatornába való belépési parancsnak. A kapcsolat megszakadása után ne csak az újracsatlakozási kísérleteket ellenőrizze, hanem az új sikeres belépés tényét is. Az automatikus újracsatlakozás hiba naplózása nélkül elrejti a lejárt tokent, a helytelen OAuth-jelszót vagy a csatornanév hibáját.

Ellenőrizze az OAuth-tokent és az olvasási jogosultságokat

A tokennek ahhoz a fiókhoz kell tartoznia, amelyen keresztül a bot a chatet olvassa. Ne keverje össze a streamer tokenjével: a csatornatulajdonos jogosultságai nem kerülnek át egy külön botfiókra. Az üzenetek IRC-n keresztüli olvasásához a chat:read scope szükséges.

Ha az üzeneteket EventSubon keresztül fogadja, a chat eseményhez egy felhasználói token szükséges user:read:chat jogosultsággal. Az engedélyezési sémától és attól függően, hogy ki hozza létre a feliratkozást, szükség lehet a bot csatornához való hozzáféréséhez szükséges jogosultságokra is, beleértve a channel:bot-ot. Ne adjon hozzá scope-okat találomra: vesse össze őket az aktuális feliratkozási sémával és azzal a fiókkal, amelynek nevében létrejön.

A felhasználói token érvényességét és a kiadott jogosultságok listáját a következő kéréssel ellenőrizheti:

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

A válaszban ellenőrizze a bejelentkezési nevet, a felhasználói azonosítót, a lejárati időt és a scopes tömböt. Ha a chat:read vagy a user:read:chat hiányzik, újra kell engedélyezni a szükséges jogosultságkészlettel. A megoldás hátránya, hogy a régi tokeneket és a mentett munkameneteket le kell cserélni a bot konfigurációjában, különben továbbra is a korábbi jogosultságokkal fog működni.

Válassza szét az IRC és az EventSub diagnosztikáját

Az IRC és az EventSub különböző útvonalakon kézbesíti az üzeneteket. Az IRC állandó kapcsolaton keresztül továbbítja a chatfolyamot: a nyers naplóban meg kell keresni a moderátortól származó PRIVMSG sort. Az EventSub a channel.chat.message eseményt egy létrehozott API-feliratkozáson keresztül továbbítja: itt annak állapotát, condition-jét és kézbesítési transportját kell ellenőrizni.

Ha a bot mindkét forrást használja, naplózza minden esemény forrását. Ellenkező esetben egy üzenet kétszer is feldolgozódhat, és az egyik transport hibája észrevétlen marad. Ha csak az EventSubot használja, az IRC-kapcsolat hiánya nem számít hibának. Az EventSub séma hátránya, hogy helytelen vagy letiltott feliratkozás esetén a bot egyáltalán nem látja az üzeneteket, még működő token mellett sem.

Ellenőrizze az EventSub-feliratkozást a chatüzenetekre

A feliratkozások listájában keresse meg a channel.chat.message eseményt. A bejegyzésnek aktív állapotúnak kell lennie. A condition-ben ellenőrizze a broadcaster_user_id-t — ez a streamer csatornájának azonosítója — és annak a felhasználónak a user_id-jét, aki az eseményeket fogadja. Bármelyik ID hibája gyakran szelektív üzenethiányként jelenik meg.

Kérje le a feliratkozások listáját a GET /helix/eventsub/subscriptions kéréssel. A válaszban ellenőrizze a type, status, condition és transport mezőket. Az enabled állapot azt jelenti, hogy a feliratkozás aktív; a kézbesítési hibáról szóló értesítés, a törölt bejegyzés vagy egy másik csatorna utal az okra. Ehhez a kéréshez annak az alkalmazásnak a tokenjét és Client ID-jét használja, amely létrehozta a feliratkozást.

Ne hagyatkozzon csak arra, hogy van-e bejegyzés a panelen vagy a bot adatbázisában. A feliratkozás létrejöhetett egy tesztcsatornához, törlődhetett egy kézbesítési hiba után, vagy egy másik alkalmazáshoz tartozhat. Az API-n keresztüli ellenőrzés hátránya, hogy megmutatja a feliratkozás konfigurációját, de nem magyarázza meg a szűrési logikát magában a kezelőben.

Kapcsolja be az IRC-tageket, és ellenőrizze a szerző szerepkörét

Ha a jogosultságellenőrzés IRC-alapú, a kliensnek kérnie kell a twitch.tv/tags capability-t. Tagek nélkül a bot megkaphatja a szöveget és a szerző becenevét, de nem látja a mod és badges mezőket. Ebben az esetben a normál parancsok megérkeznek, a moderátorszabályok viszont tévesen elutasítanak.

A moderátor nyers üzenetében keresse a mod=1 és a badges=moderator/1 értékeket. A user-type mező hiányozhat, üres lehet, vagy nem felelhet meg az aktuális szerepkörnek, ezért ne használja egyetlen ismertetőjelként. A parsernek helyesen kell kezelnie az üres tagértékeket és az escape-elt karaktereket; az IRC-megközelítés hátránya éppen az, hogy ezt a formátumot magának kell feldolgoznia.

Ha nincs mod=1, először győződjön meg arról, hogy a tagekhez szükséges capability-t valóban megerősítette a szerver, nem csak a kliens küldte el. Ezután ellenőrizze a badges mezőt. A moderator/1 érték moderátort, a broadcaster/1 a csatorna tulajdonosát jelenti. A VIP általában vip/1 badge-dzsel rendelkezik, de a VIP nem válik automatikusan moderátorrá. A streamert és a VIP-et ne tekintse moderátornak a becenév, a szín vagy a display-name alapján: a szerepkört a badges és a külön hozzáférési szabályok alapján határozza meg.

Ellenőrizze a szerepkörszabályokat a kódban és a beállításokban

Hasonlítsa össze egy néző, egy VIP, egy moderátor és a csatornatulajdonos nyers eseményeit azonos szöveggel. Ha a moderátor eseménye eljutott az alkalmazáshoz, de a kezelő kihagyta, a hiba a fogadás után van: a szerepkör ellenőrzésében, a feketelistában, az antispamben vagy a parancsok útvonalválasztásában.

• Az összehasonlítás előtt egységesítse a bejelentkezési nevek kis- és nagybetűit.
• Ellenőrizze a mod=1 és a moderator badge mezőket, ne egyetlen rögzített tagkészletet.
• Külön határozza meg a broadcaster, moderator, vip és magának a botnak a fiókjára vonatkozó jogosultságokat.
• Ellenőrizze, hogy a moderátor nem került-e az ignorálási listára, a banlistára vagy a tiltott felhasználók listájára.
• Nézze meg a feltételek sorrendjét: az antispam vagy a tiltott szavak a szerepkör ellenőrzése előtt is aktiválódhatnak.
• Győződjön meg arról, hogy a parancsot nem blokkolja az említést, hivatkozást vagy szövegismétlést tartalmazó üzenetekre vonatkozó szabály.

A kézi becenévlista csak rövid diagnosztikára alkalmas. Hátránya, hogy elavul a moderátorok cseréje, a fiók átnevezése vagy a csatornában a szerepkörök megváltozása után.

Zárja ki a parancsformátumot, a limiteket és a rejtett ignorálást

A bot láthatja az üzenetet, és szándékosan nem válaszolhat. Ellenőrizze a parancs cooldownját, az egy felhasználótól érkező üzenetek limitjét, az ismétlés elleni védelmet, az emodzsi- és tiltottszó-szűrőt. A moderátorok gyakran gyorsan küldik a parancsokat, és ugyanúgy az antispam hatálya alá kerülhetnek, mint a nézők.

Külön teszteljen egy normál mondatot és egy előtaggal ellátott parancsot. Ha a mondat szerepel a naplóban, de a parancs nem jutott el a feldolgozás eredményéig, ellenőrizze az előtagot, a billentyűzetkiosztást, a szóközöket, a láthatatlan karaktereket és az argumentumokat. A perjellel kezdődő parancsok és a moderációs műveletek nem mindig a kezelő által várt normál szövegként érkeznek.

Naplózza minden üzenet döntésének okát

A diagnosztikához mentse el az időt, az esemény forrását, a csatornát, a szerző ID-jét, az üzenet típusát, a tageket és a feldolgozás eredményét. A szöveget maszkolhatja, ha nincs szükség rá a hiba kereséséhez. A naplóban konkrét oknak kell szerepelnie: az üzenet nem érkezett meg, a szerepkör nem került felismerésre, nem ment át az előtag, aktiválódott a cooldown, a felhasználó az ignorálási listán van, vagy le van tiltva az EventSub-feliratkozás.

Ne írjon a normál naplókba OAuth-tokeneket, alkalmazástitkot, webhook-címeket és teljes engedélyezési fejléceket. Ezek az adatok hasznosak a hibakeresésnél, de kiszivárgásuk hozzáférést nyithat a bothoz és az alkalmazás beállításaihoz.

Diagnosztikai ellenőrzőlista sorrendben

1. Küldjön ugyanazt a mondatot és ugyanazt a parancsot egy nézőtől és egy moderátortól.
2. Ellenőrizze a nyers naplót, és állapítsa meg, hogy az üzenet IRC-n, EventSubon vagy mindkét forráson keresztül érkezett-e.
3. Ha az IRC nem kap üzeneteket, vesse össze a bot fiókját, a csatorna nevét, a tokent és a sikeres chatbelépést.
4. Ha az IRC-üzenet megérkezett, győződjön meg arról, hogy a tagek be vannak kapcsolva, majd ellenőrizze a mod=1 és a badges=moderator/1 értékeket.
5. Ha nincs mod=1, ellenőrizze a twitch.tv/tags megerősítését, és különböztesse meg a moderator/1, vip/1 és broadcaster/1 értékeket.
6. Ellenőrizze a tokent a validate kéréssel: IRC-hez chat:read, EventSub-üzenetekhez user:read:chat szükséges.
7. EventSub használata esetén ellenőrizze a channel.chat.message eseményt, az enabled állapotot, a condition-t és a transportot a feliratkozások listájában.
8. Hasonlítsa össze a szerepkörök feldolgozását, az ignorálási listát, az antispamot, az előtagot, a cooldownt és a tiltott szavakat.
9. Adja hozzá a naplóhoz annak egyértelmű okát, hogy az egyes üzeneteket miért fogadta el, hagyta figyelmen kívül vagy utasította el.