لماذا يتجاهل بوت Twitch رسائل المشرفين

حدّد أولاً في أي مرحلة تختفي الرسالة

تحقق مما إذا كان البوت يستقبل الرسائل العادية في القناة نفسها. إذا لم تظهر في السجلات رسائل المشاهدين ولا المشرفين، فالمشكلة عادةً في التفويض أو الاتصال بالدردشة أو اسم القناة. أما إذا كانت رسائل المشاهدين ظاهرة ورسائل المشرف غائبة، فابحث عن السبب في فلتر الأدوار أو وسوم IRC أو اشتراك EventSub.

لا تنظر فقط إلى رد البوت في الدردشة، بل إلى سجل الأحداث الواردة. قد تصل الرسالة إلى التطبيق لكنها لا تشغّل الأمر بسبب البادئة أو فترة الانتظار أو الكلمات المحظورة أو قائمة التجاهل أو فحص الصلاحيات. للاختبار، أرسل من مشاهد ومن مشرف عبارة قصيرة متطابقة، ثم أمرًا متطابقًا.

تحقق من القناة وحساب البوت واتصال IRC

تأكد من أن البوت دخل القناة الصحيحة وبالحساب الذي يجب أن يقرأ الدردشة. بعد إعادة تسمية القناة أو تغيير تسجيل الدخول أو التبديل بين بيئة الاختبار وبيئة العمل، قد يبقى التطبيق متصلاً لكنه يستمع إلى دردشة أخرى.

يجب أن يظهر في سجل الاتصال نجاح التفويض واسم البوت وأمر الدخول إلى القناة. بعد انقطاع الاتصال، تحقق ليس فقط من محاولات إعادة الاتصال، بل من نجاح الدخول من جديد. إعادة الاتصال التلقائي دون تسجيل الخطأ تخفي رمزًا منتهي الصلاحية أو كلمة مرور OAuth خاطئة أو خطأً في اسم القناة.

تحقق من رمز OAuth وصلاحيات القراءة

يجب أن يكون الرمز مملوكًا للحساب الذي يقرأ البوت الدردشة من خلاله. لا تخلطه برمز صاحب البث: صلاحيات مالك القناة لا تُنقل إلى حساب بوت منفصل. لقراءة الرسائل عبر IRC يلزم النطاق chat:read.

إذا كانت الرسائل تُستقبل عبر EventSub، فيلزم لحدث الدردشة رمز مستخدم بصلاحية user:read:chat. وبحسب مخطط التفويض ومن ينشئ الاشتراك، قد تلزم أيضًا صلاحيات وصول البوت إلى القناة، بما في ذلك channel:bot. لا تضف النطاقات عشوائيًا: طابقها مع مخطط الاشتراك الحالي والحساب الذي يُنشأ باسمه.

يمكن التحقق من صلاحية رمز المستخدم وقائمة الصلاحيات الممنوحة بالطلب التالي:

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 ووسيلة النقل.

إذا كان البوت يستخدم المصدرين معًا، فسجّل مصدر كل حدث في السجل. وإلا فقد تُعالج الرسالة نفسها مرتين، ويبقى عطل أحد الناقلين غير ملحوظ. إذا كان EventSub وحده مستخدمًا، فغياب اتصال IRC لا يُعد خطأً. عيب مخطط EventSub أنه عند اشتراك خاطئ أو معطّل لن يرى البوت الرسائل إطلاقًا، حتى مع رمز صالح.

تحقق من اشتراك EventSub على رسائل الدردشة

في قائمة الاشتراكات ابحث عن الحدث channel.chat.message. يجب أن تكون حالة السجل نشطة. في condition تحقق من broadcaster_user_id — وهو معرّف قناة صاحب البث — ومن user_id للمستخدم الذي يستقبل الأحداث. الخطأ في أي من هذين المعرّفين غالبًا ما يظهر كغياب انتقائي للرسائل.

اطلب قائمة الاشتراكات عبر GET /helix/eventsub/subscriptions. في الرد تحقق من type وstatus وcondition وtransport. الحالة enabled تعني أن الاشتراك نشط؛ وإشعارات فشل التسليم أو سجل محذوف أو قناة مختلفة ستشير إلى السبب. لهذا الطلب استخدم رمز وClient ID التطبيق الذي أنشأ الاشتراك.

لا تعتمد فقط على وجود سجل في لوحة التحكم أو قاعدة بيانات البوت. قد يكون الاشتراك منشأً لقناة اختبار أو محذوفًا بعد خطأ تسليم أو تابعًا لتطبيق آخر. عيب التحقق عبر API أنه يُظهر إعدادات الاشتراك لكنه لا يفسّر منطق الفلترة داخل المعالج نفسه.

فعّل وسوم IRC وتحقق من دور الكاتب

إذا كان فحص الصلاحيات مبنيًا على IRC، فيجب أن يطلب العميل القدرة twitch.tv/tags. بدون الوسوم قد يستقبل البوت النص واسم الكاتب لكنه لا يرى الحقلين mod وbadges. في هذه الحالة تصل الأوامر العادية، لكن قواعد المشرفين تعطي رفضًا خاطئًا.

في الرسالة الخام من المشرف ابحث عن mod=1 وbadges=moderator/1. قد يكون الحقل user-type غائبًا أو فارغًا أو غير مطابق للدور الحالي، لذا لا تستخدمه كدليل وحيد. يجب أن يعالج المحلل القيم الفارغة للوسوم والأحرف المهرّبة بشكل صحيح؛ وعيب نهج IRC تحديدًا هو الحاجة إلى تحليل هذا التنسيق يدويًا.

إذا لم يكن mod=1 موجودًا، فتأكد أولاً من أن الخادم أكّد فعلًا قدرة الوسوم، لا أن العميل أرسلها فقط. ثم تحقق من badges. القيمة moderator/1 تعني مشرفًا، وbroadcaster/1 تعني مالك القناة. عادةً يحمل VIP شارة vip/1، لكن VIP لا يصبح مشرفًا تلقائيًا. لا ينبغي اعتبار صاحب البث وVIP مشرفين بناءً على الاسم أو اللون أو display-name: حدّد الدور من badges وقواعد الوصول المنفصلة.

تحقق من قواعد الأدوار في الكود والإعدادات

قارن الأحداث الخام من مشاهد وVIP ومشرف ومالك القناة بنص متطابق. إذا وصل حدث المشرف إلى التطبيق لكن المعالج تجاهله، فالخطأ بعد الاستقبال: في فحص الدور أو القائمة السوداء أو مكافحة السبام أو توجيه الأوامر.

• وحّد حالة الأحرف في أسماء الدخول قبل المقارنة.
• تحقق من mod=1 وشارة moderator، لا من مجموعة وسوم ثابتة واحدة.
• حدّد الصلاحيات بشكل منفصل لـ broadcaster وmoderator وvip وحساب البوت نفسه.
• تحقق مما إذا كان المشرف قد أُدرج في قائمة التجاهل أو الحظر أو قائمة المستخدمين المحظورين.
• راجع ترتيب الشروط: قد تعمل مكافحة السبام أو الكلمات المحظورة قبل فحص الدور.
• تأكد من أن الأمر لا يُحظر بقاعدة تخص الرسائل التي تحتوي على إشارة أو رابط أو تكرار نص.

قائمة الأسماء اليدوية تصلح فقط للتشخيص السريع. عيبها أنها تصبح قديمة بعد تغيير المشرفين أو إعادة تسمية الحساب أو تغيير الأدوار في القناة.

استبعد تنسيق الأمر والحدود والتجاهل الخفي

قد يرى البوت الرسالة ولا يرد عليها عمدًا. تحقق من فترة انتظار الأمر وحد الرسائل من مستخدم واحد والحماية من التكرار وفلتر الإيموجي والكلمات المحظورة. غالبًا ما يرسل المشرفون الأوامر بسرعة وقد يقعون تحت مكافحة السبام مثل المشاهدين.

اختبر بشكل منفصل عبارة عادية وأمرًا ببادئة. إذا كانت العبارة موجودة في السجل لكن الأمر لم يصل إلى نتيجة المعالجة، فتحقق من البادئة وتخطيط لوحة المفاتيح والمسافات والأحرف غير المرئية والوسائط. الأوامر التي تبدأ بشرطة مائلة وإجراءات الإشراف لا تصل دائمًا كنص عادي يتوقعه المعالج.

سجّل سبب القرار لكل رسالة

للتشخيص احفظ الوقت ومصدر الحدث والقناة ومعرّف الكاتب ونوع الرسالة والوسوم ونتيجة المعالجة. يمكن إخفاء النص إذا لم يكن لازمًا للعثور على الخطأ. يجب أن يحتوي السجل على سبب محدد: لم تُستقبل الرسالة، أو لم يُتعرّف على الدور، أو لم تجتز البادئة، أو عملت فترة الانتظار، أو المستخدم في قائمة التجاهل، أو اشتراك EventSub معطّل.

لا تسجّل في السجلات العادية رموز OAuth أو سر التطبيق أو عناوين webhooks أو ترويسات التفويض الكاملة. هذه البيانات مفيدة عند التصحيح، لكن تسريبها قد يفتح الوصول إلى البوت وإعدادات التطبيق.

قائمة تحقق التشخيص بالترتيب

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: يلزم chat:read لـ IRC، وuser:read:chat لرسائل EventSub.
7. عند العمل عبر EventSub تحقق من channel.chat.message والحالة enabled وcondition وtransport في قائمة الاشتراكات.
8. قارن معالجة الأدوار وقائمة التجاهل ومكافحة السبام والبادئة وفترة الانتظار والكلمات المحظورة.
9. أضف إلى السجل سببًا صريحًا لقبول كل رسالة أو تجاهلها أو رفضها.