ควรทำอย่างไรเมื่อบอทแชทตอบในไลฟ์สดสองครั้ง

ก่อนอื่นให้ระบุประเภทของข้อความซ้ำ

การตอบสองครั้งที่เหมือนกันติดกันไม่ใช่ความเสียหายเดียว แต่มีอย่างน้อยสองแบบที่แตกต่างกัน กรณีแรก: บอทได้รับเหตุการณ์เดียวแต่สองครั้ง กรณีที่สอง: เหตุการณ์มาเพียงครั้งเดียว แต่บอทส่งไปสองครั้ง ทั้งสองกรณีแก้ต่างกัน ดังนั้นอย่าเริ่มจากการแก้โค้ด — เริ่มจากบันทึก

เปิดบันทึกของบอทและหาโมเมนต์ที่เกิดข้อความซ้ำ จากนั้นดูสองฟิลด์: ตัวระบุเหตุการณ์และเวลาที่ได้รับ

• คำขอสองรายการที่มี event_id เดียวกัน (หรือ message_id, notification_id — ชื่อขึ้นอยู่กับแพลตฟอร์ม) และต่างกันเพียงมิลลิวินาที — นี่คือการส่งเหตุการณ์เดิมซ้ำ ให้มองหาการดีดูพลิเคชัน
• คำขอสองรายการที่มีตัวระบุต่างกัน — มีตัวจัดการสองตัวสมัครรับช่องจริงๆ ให้มองหาการสมัครสมาชิกตัวที่สอง

หากไม่มีบันทึกเลย ให้เริ่มจากแผงควบคุมของแพลตฟอร์ม: ที่นั่นจะเห็นว่าใครสมัครรับเหตุการณ์ของช่อง

การสมัครสมาชิกซ้ำในแผงควบคุมมีหน้าตาอย่างไร

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

Twitch

ตรวจสอบส่วน Connections ในการตั้งค่าบัญชี — ที่นั่นมีรายการแอปที่เชื่อมต่ออยู่ บอทตัวเดียวกันอาจได้รับอนุญาตทั้งในฐานะแอปของช่องและแอปของบัญชีส่วนตัวของคุณ นอกจากนี้การสมัครรับ EventSub ยังแยกอยู่ต่างหาก: แอปอาจมีการสมัครรับ channel.chat.message ที่ยังใช้งานอยู่หลังจากที่คุณปิดการเชื่อมต่อในแผงควบคุมแล้ว อินสแตนซ์ที่สองของบอทที่รันในเครื่องก็ได้รับเหตุการณ์เช่นเดียวกับตัวที่ทำงานอยู่

YouTube

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

Discord

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

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

การส่งเว็บฮุกซ้ำ: ทำไมเหตุการณ์จึงมาสองครั้ง

บริการภายนอกส่งเว็บฮุกและรอการยืนยัน หากไม่ได้รับการยืนยันภายในเวลาที่กำหนด — จะส่งอีกครั้ง คำขอที่สองมีเหตุการณ์เดิม แต่บอทกลับมองว่าเป็นเหตุการณ์ใหม่และตอบอีกครั้ง สิ่งนี้เกิดขึ้นเมื่อเซิร์ฟเวอร์ค้างในทุกกรณี: ยิ่งโหลดมาก ยิ่งเกิดบ่อย

แก้ได้ด้วยการดีดูพลิเคชันฝั่งบอท ต้องมีคีย์ที่เหมือนกันสำหรับสำเนาทั้งหมดของเหตุการณ์เดียวและไม่ซ้ำสำหรับเหตุการณ์ที่ต่างกัน คีย์ดึงมาจากเนื้อหาคำขอหรือเฮดเดอร์ — ขึ้นอยู่กับ API แต่รูปแบบเหมือนกัน

ตัวอย่างคีย์ดีดูพลิเคชัน

ลองนึกถึงเว็บฮุกเกี่ยวกับโดเนทใหม่ ในเนื้อหามีออบเจกต์ที่มีฟิลด์ id — หมายเลขธุรกรรมที่ไม่ซ้ำ ซึ่งไม่เปลี่ยนเมื่อส่งซ้ำ ตรรกะเป็นเช่นนี้:

1. เมื่อได้รับคำขอ ให้ดึง id จากเนื้อหา
2. ตรวจสอบในที่จัดเก็บ (Redis, ตารางในฐานข้อมูล) ว่าเคยพบหรือไม่ในช่วง เช่น หนึ่งวันที่ผ่านมา
3. หากเคยพบ — ตอบบริการว่า "รับแล้ว" และไม่ส่งอะไรไปยังแชท
4. หากไม่เคย — บันทึกและประมวลผลตามปกติ

คีย์ต้องมาจากเหตุการณ์ ไม่ใช่ที่คุณสร้างขึ้นเอง: หากสร้างเอง การส่งสองครั้งของเหตุการณ์เดียวจะได้คีย์ที่ต่างกัน และการดีดูพลิเคชันจะไม่ทำงาน บางแพลตฟอร์มมีเฮดเดอร์สำเร็จรูปที่มีตัวระบุการส่ง — หากมีให้ใช้เฮดเดอร์นั้น ซึ่งเชื่อถือได้กว่า ข้อเสียของวิธีนี้คือต้องมีที่จัดเก็บและนโยบายการล้างข้อมูล ไม่เช่นนั้นฐานคีย์จะโตขึ้นไม่มีขีดจำกัด

หากข้อความซ้ำมาจากสองแหล่งที่ต่างกัน

อีกเรื่องแยกต่างหาก — เมื่อเหตุการณ์ไม่ได้ถูกส่งซ้ำ แต่มาจากสองที่จริงๆ กรณีคลาสสิก: บอทตอบคำสั่งทั้งในแชทและในการส่งต่อระหว่างแพลตฟอร์มผ่านบริดจ์ หรือการตอบกลับอัตโนมัติตั้งค่าไว้กับทริกเกอร์สองตัวที่ทำงานกับวลีเดียวกัน

ข้อความซ้ำประเภทนี้ต่างจากการส่งเว็บฮุกซ้ำเมื่อดูจากบันทึก: คำขอมีแหล่งที่มาต่างกัน (แพลตฟอร์มต่างกัน ตัวจัดการต่างกัน) แต่เป็นเหตุการณ์เชิงความหมายเดียวกัน ให้มองหาทริกเกอร์ที่ทับซ้อนกันและปิดหนึ่งในนั้น สำหรับบริดจ์ — อย่าส่งข้อความของบอทเองกลับไป

การตรวจสอบก่อนไลฟ์สด

1. ส่งคำสั่งทดสอบและดูว่ามีคำตอบกี่รายการ
2. ปิดการเชื่อมต่อทั้งหมดยกเว้นหนึ่ง แล้วทำซ้ำ
3. เปิดทีละตัวจนกว่าข้อความซ้ำจะกลับมา — วิธีนี้จะหาตัวการได้
4. เทียบตัวระบุเหตุการณ์ของคำตอบทั้งสองจากบันทึก: เหมือนกัน — คือการส่งซ้ำ, ต่างกัน — คือการสมัครสมาชิกตัวที่สอง

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