ทำไมบอท Twitch จึงข้ามข้อความของผู้ดูแล

ก่อนอื่นให้ระบุว่าข้อความหายไปในขั้นตอนใด

ตรวจสอบว่าบอทได้รับข้อความปกติในช่องเดียวกันหรือไม่ หากในบันทึกไม่มีทั้งผู้ชมและผู้ดูแล ปัญหามักอยู่ที่การอนุญาต การเชื่อมต่อแชท หรือชื่อช่อง หากเห็นผู้ชมแต่ไม่มีข้อความของผู้ดูแล ให้มองหาสาเหตุในตัวกรองบทบาท แท็ก IRC หรือการสมัครรับ EventSub

อย่าดูเพียงการตอบกลับของบอทในแชท แต่ให้ดูบันทึกเหตุการณ์ขาเข้าด้วย ข้อความอาจมาถึงแอปแล้วแต่ไม่ทริกเกอร์คำสั่งเนื่องจากคำนำหน้า คูลดาวน์ คำต้องห้าม รายการเพิกเฉย หรือการตรวจสอบสิทธิ์ สำหรับการทดสอบ ให้ส่งวลีสั้น ๆ เดียวกันและคำสั่งเดียวกันจากทั้งผู้ชมและผู้ดูแล

ตรวจสอบช่อง บัญชีบอท และการเชื่อมต่อ IRC

ตรวจสอบให้แน่ใจว่าบอทเข้าสู่ช่องที่ถูกต้องและใช้บัญชีที่ควรอ่านแชท หลังจากเปลี่ยนชื่อช่อง เปลี่ยนชื่อล็อกอิน หรือสลับระหว่างสภาพแวดล้อมทดสอบและใช้งานจริง แอปอาจยังออนไลน์อยู่แต่ฟังแชทอื่นอยู่

ในบันทึกการเชื่อมต่อควรเห็นการอนุญาตที่สำเร็จ ชื่อบอท และคำสั่งเข้าช่อง หลังจากเชื่อมต่อขาดหาย ให้ตรวจสอบไม่เพียงความพยายามเชื่อมต่อใหม่ แต่รวมถึงการเข้าสู่ระบบที่สำเร็จครั้งใหม่ด้วย การเชื่อมต่อใหม่อัตโนมัติโดยไม่บันทึกข้อผิดพลาดจะปกปิดโทเค็นที่หมดอายุ รหัสผ่าน OAuth ที่ผิด หรือข้อผิดพลาดในชื่อช่อง

ตรวจสอบโทเค็น OAuth และสิทธิ์ในการอ่าน

โทเค็นต้องเป็นของบัญชีที่บอทใช้อ่านแชท อย่าสับสนกับโทเค็นของสตรีมเมอร์: สิทธิ์ของเจ้าของช่องไม่ได้ถูกส่งต่อไปยังบัญชีบอทแยกต่างหาก สำหรับการอ่านข้อความผ่าน IRC ต้องมี scope chat:read

หากรับข้อความผ่าน EventSub สำหรับเหตุการณ์แชทต้องใช้โทเค็นผู้ใช้ที่มีสิทธิ์ user:read:chat ขึ้นอยู่กับรูปแบบการอนุญาตและผู้ที่สร้างการสมัครรับ อาจต้องมีสิทธิ์สำหรับการเข้าถึงช่องของบอทด้วย รวมถึง channel:bot อย่าเพิ่ม scope แบบสุ่มเดา: ให้ตรวจสอบเทียบกับรูปแบบการสมัครรับปัจจุบันและบัญชีที่ใช้สร้าง

ตรวจสอบความถูกต้องของโทเค็นผู้ใช้และรายการสิทธิ์ที่ให้ไว้ได้ด้วยคำขอ:

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

ในคำตอบให้ตรวจสอบล็อกอิน รหัสผู้ใช้ ระยะเวลาหมดอายุ และอาร์เรย์ scopes หากไม่มี chat:read หรือ user:read:chat จะต้องอนุญาตใหม่ด้วยชุดสิทธิ์ที่ต้องการ ข้อเสียของวิธีนี้คือต้องแทนที่โทเค็นเก่าและเซสชันที่บันทึกไว้ในการตั้งค่าบอท มิฉะนั้นบอทจะยังทำงานด้วยสิทธิ์เดิม

แยกการวินิจฉัย IRC และ EventSub

IRC และ EventSub ส่งข้อความผ่านเส้นทางที่ต่างกัน IRC ส่งสตรีมแชทผ่านการเชื่อมต่อถาวร: ในบันทึกดิบต้องหาบรรทัด PRIVMSG จากผู้ดูแล EventSub ส่งเหตุการณ์ channel.chat.message ผ่านการสมัครรับ API ที่สร้างขึ้น: ที่นี่ให้ตรวจสอบสถานะ condition และ transport ของการส่ง

หากบอทใช้ทั้งสองแหล่ง ให้บันทึกแหล่งที่มาของแต่ละเหตุการณ์ลงในบันทึก มิฉะนั้นข้อความเดียวอาจถูกประมวลผลซ้ำ และความล้มเหลวของ transport หนึ่งจะมองไม่เห็น หากใช้เฉพาะ EventSub การไม่มีการเชื่อมต่อ IRC ไม่ถือเป็นข้อผิดพลาด ข้อเสียของรูปแบบ EventSub คือหากการสมัครรับผิดหรือถูกปิด บอทจะไม่เห็นข้อความเลยแม้โทเค็นจะใช้งานได้

ตรวจสอบการสมัครรับ EventSub สำหรับข้อความแชท

ในรายการการสมัครรับ ให้ค้นหาเหตุการณ์ channel.chat.message รายการต้องมีสถานะใช้งานอยู่ ใน condition ให้ตรวจสอบ broadcaster_user_id ซึ่งเป็นรหัสของช่องสตรีมเมอร์ และ user_id ของผู้ใช้ที่รับเหตุการณ์ ข้อผิดพลาดใน ID ใด ๆ เหล่านี้มักดูเหมือนข้อความหายไปแบบเลือกได้

ขอรายการการสมัครรับผ่าน GET /helix/eventsub/subscriptions ในคำตอบให้ตรวจสอบ type, status, condition และ transport สถานะ enabled หมายถึงการสมัครรับใช้งานอยู่; การแจ้งเตือนความล้มเหลวในการส่ง รายการที่ถูกลบ หรือช่องอื่นจะบ่งชี้สาเหตุ สำหรับคำขอนี้ให้ใช้โทเค็นและ Client ID ของแอปที่สร้างการสมัครรับ

อย่าอ้างอิงเพียงการมีรายการในแผงควบคุมหรือฐานข้อมูลของบอท การสมัครรับอาจถูกสร้างสำหรับช่องทดสอบ ถูกลบหลังเกิดข้อผิดพลาดในการส่ง หรือเป็นของแอปอื่น ข้อเสียของการตรวจสอบผ่าน API คือแสดงการตั้งค่าการสมัครรับ แต่ไม่อธิบายตรรกะการกรองภายในตัวจัดการเอง

เปิดใช้แท็ก IRC และตรวจสอบบทบาทของผู้ส่ง

หากการตรวจสอบสิทธิ์อิงกับ IRC ไคลเอนต์ต้องขอ capability twitch.tv/tags หากไม่มีแท็ก บอทอาจได้รับข้อความและชื่อผู้ส่ง แต่ไม่เห็นฟิลด์ mod และ badges ในกรณีนั้นคำสั่งปกติจะมาถึง แต่กฎสำหรับผู้ดูแลจะปฏิเสธอย่างผิดพลาด

ในข้อความดิบของผู้ดูแล ให้ค้นหา mod=1 และ badges=moderator/1 ฟิลด์ user-type อาจไม่มี ว่างเปล่า หรือไม่ตรงกับบทบาทปัจจุบัน ดังนั้นอย่าใช้เป็นเครื่องหมายเดียว ตัวแยกวิเคราะห์ต้องจัดการค่าที่ว่างของแท็กและอักขระที่ถูก escape อย่างถูกต้อง; ข้อเสียของวิธี IRC คือต้องแยกวิเคราะห์รูปแบบนี้ด้วยตนเอง

หากไม่มี mod=1 ก่อนอื่นให้ตรวจสอบว่า capability สำหรับแท็กได้รับการยืนยันจากเซิร์ฟเวอร์จริง ไม่ใช่เพียงส่งจากไคลเอนต์ จากนั้นตรวจสอบ badges ค่า moderator/1 หมายถึงผู้ดูแล broadcaster/1 คือเจ้าของช่อง VIP โดยปกติมี badge vip/1 แต่ VIP ไม่ได้กลายเป็นผู้ดูแลโดยอัตโนมัติ ไม่ควรถือสตรีมเมอร์และ VIP เป็นผู้ดูแลจากชื่อ สี หรือ display-name: ให้กำหนดบทบาทจาก badges และกฎการเข้าถึงแยกต่างหาก

ตรวจสอบกฎบทบาทในโค้ดและการตั้งค่า

เปรียบเทียบเหตุการณ์ดิบจากผู้ชม VIP ผู้ดูแล และเจ้าของช่องที่มีข้อความเดียวกัน หากเหตุการณ์จากผู้ดูแลมาถึงแอปแล้วแต่ตัวจัดการข้ามไป ข้อผิดพลาดอยู่หลังการรับ: ในการตรวจสอบบทบาท บัญชีดำ ระบบป้องกันสแปม หรือการกำหนดเส้นทางคำสั่ง

• ปรับล็อกอินให้เป็นตัวพิมพ์เดียวกันก่อนเปรียบเทียบ
• ตรวจสอบ mod=1 และ badge moderator ไม่ใช่ชุดแท็กตายตัวชุดเดียว
• กำหนดสิทธิ์แยกสำหรับ broadcaster, moderator, vip และบัญชีของบอทเอง
• ตรวจสอบว่าผู้ดูแลไม่ได้อยู่ในรายการเพิกเฉย แบน หรือรายการผู้ใช้ต้องห้าม
• ดูลำดับเงื่อนไข: ระบบป้องกันสแปมหรือคำต้องห้ามอาจทำงานก่อนการตรวจสอบบทบาท
• ตรวจสอบว่าคำสั่งไม่ถูกบล็อกโดยกฎสำหรับข้อความที่มีการกล่าวถึง ลิงก์ หรือข้อความซ้ำ

รายการชื่อด้วยมือเหมาะสำหรับการวินิจฉัยระยะสั้นเท่านั้น ข้อเสียคือล้าสมัยหลังจากเปลี่ยนผู้ดูแล เปลี่ยนชื่อบัญชี หรือเปลี่ยนบทบาทในช่อง

ตัดปัจจัยเรื่องรูปแบบคำสั่ง ขีดจำกัด และการเพิกเฉยที่ซ่อนอยู่

บอทอาจเห็นข้อความและเลือกที่จะไม่ตอบ ตรวจสอบคูลดาวน์ของคำสั่ง ขีดจำกัดข้อความจากผู้ใช้คนเดียว การป้องกันข้อความซ้ำ ตัวกรองอีโมจิ และคำต้องห้าม ผู้ดูแลมักส่งคำสั่งอย่างรวดเร็วและอาจถูกระบบป้องกันสแปมเช่นเดียวกับผู้ชม

ทดสอบแยกต่างหากด้วยวลีปกติและคำสั่งที่มีคำนำหน้า หากวลีอยู่ในบันทึกแต่คำสั่งไม่ถึงผลลัพธ์การประมวลผล ให้ตรวจสอบคำนำหน้า แป้นพิมพ์ ช่องว่าง อักขระที่มองไม่เห็น และอาร์กิวเมนต์ คำสั่งที่มีสแลชและการดำเนินการดูแลไม่ได้มาในรูปแบบข้อความปกติที่ตัวจัดการคาดหวังเสมอไป

บันทึกเหตุผลการตัดสินใจสำหรับแต่ละข้อความ

สำหรับการวินิจฉัย ให้บันทึกเวลา แหล่งที่มาของเหตุการณ์ ช่อง ID ผู้ส่ง ประเภทข้อความ แท็ก และผลลัพธ์การประมวลผล สามารถปิดบังข้อความได้หากไม่จำเป็นสำหรับการค้นหาข้อผิดพลาด ในบันทึกต้องมีสาเหตุที่ชัดเจน: ไม่ได้รับข้อความ ไม่รู้จักบทบาท คำนำหน้าไม่ผ่าน คูลดาวน์ทำงาน ผู้ใช้อยู่ในรายการเพิกเฉย หรือการสมัครรับ EventSub ถูกปิด

อย่าบันทึกโทเค็น OAuth ซีเคร็ตของแอป ที่อยู่เว็บฮุก และส่วนหัวการอนุญาตแบบเต็มลงในบันทึกปกติ ข้อมูลเหล่านี้มีประโยชน์ในการดีบัก แต่การรั่วไหลอาจเปิดการเข้าถึงบอทและการตั้งค่าแอป

รายการตรวจสอบการวินิจฉัยตามลำดับ

1. ส่งวลีเดียวกันและคำสั่งเดียวกันจากผู้ชมและผู้ดูแล
2. ตรวจสอบบันทึกดิบและระบุว่าข้อความมาผ่าน IRC, EventSub หรือทั้งสองแหล่ง
3. หาก IRC ไม่ได้รับข้อความ ให้ตรวจสอบบัญชีบอท ชื่อช่อง โทเค็น และการเข้าสู่แชทที่สำเร็จ
4. หากข้อความ IRC มาแล้ว ให้ตรวจสอบว่าเปิดใช้แท็ก แล้วตรวจสอบ mod=1 และ badges=moderator/1
5. หากไม่มี mod=1 ให้ตรวจสอบการยืนยัน twitch.tv/tags และแยกแยะ moderator/1, vip/1 และ broadcaster/1
6. ตรวจสอบโทเค็นผ่าน validate: สำหรับ IRC ต้องมี chat:read สำหรับข้อความ EventSub ต้องมี user:read:chat
7. เมื่อทำงานผ่าน EventSub ให้ตรวจสอบ channel.chat.message สถานะ enabled, condition และ transport ในรายการการสมัครรับ
8. เปรียบเทียบการจัดการบทบาท รายการเพิกเฉย ระบบป้องกันสแปม คำนำหน้า คูลดาวน์ และคำต้องห้าม
9. เพิ่มสาเหตุที่ชัดเจนลงในบันทึกว่าทำไมแต่ละข้อความจึงถูกยอมรับ เพิกเฉย หรือปฏิเสธ