ماذا تفعل إذا رد روبوت الدردشة على البث مرتين

أولاً حدّد نوع التكرار

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

افتح سجل الروبوت وابحث عن لحظة التكرار. ثم انظر إلى حقلين: معرّف الحدث ووقت الاستقبال.

• طلبان يحملان نفس event_id (أو message_id، notification_id — الاسم يعتمد على المنصة) بفارق أجزاء من الثانية — هذا إعادة تسليم لحدث واحد. ابحث عن إزالة التكرار.
• طلبان بمعرّفات مختلفة — إذن هناك معالجان مشتركان فعلياً في القناة. ابحث عن الاشتراك الثاني.

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

كيف يبدو الاشتراك المزدوج في اللوحات

المنصات لا تُظهر «الروبوت متصل مرتين» في سطر واحد. العلامات موزعة على أقسام مختلفة.

Twitch

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

YouTube

هنا غالباً لا يكون الروبوت نفسه هو المذنب، بل الوصول إلى الدردشة: الروبوت متصل بالبث كمشرف وكحساب مشارك منفصل معاً. تحقق من قائمة المشرفين وقائمة التطبيقات المصرّح بها للقناة. وبشكل منفصل — إذا كان الروبوت يعمل عبر عدة مشاريع Google Cloud، فقد تمر المفاتيح عبر مسارين مختلفين.

Discord

أوضح حالة: تطبيقان بنفس التوكن على خادم واحد. كلاهما يرى الرسالة في القناة وكلاهما يرد عليها. تحقق من قائمة الروبوتات في الخادم وتأكد من عدم اتصال webhook ثانٍ بنفس الاسم بالقناة.

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

تكرار الـ webhook: لماذا يصل الحدث مرتين

الخدمة الخارجية تسلّم الـ webhook وتنتظر التأكيد. إذا لم تتلقَّ التأكيد في الوقت المحدد — ترسل مرة أخرى. الطلب الثاني يحمل نفس الحدث، لكن الروبوت يعتبره جديداً ويرد مجدداً. يحدث هذا عند أي تعليق في الخادم: كلما زاد الحمل، زاد تكراره.

العلاج هو إزالة التكرار من جهة الروبوت. تحتاج إلى مفتاح يكون متطابقاً لجميع نسخ الحدث الواحد وفريداً للأحداث المختلفة. يُؤخذ المفتاح من جسم الطلب أو من الترويسات — يعتمد ذلك على الـ API، لكن المخطط واحد.

مثال على مفتاح إزالة التكرار

تخيّل webhook عن تبرع جديد. يصل في الجسم كائن يحوي حقل id — رقم فريد للمعاملة لا يتغير عند إعادة التسليم. المنطق كالتالي:

1. عند استقبال الطلب، استخرج id من الجسم.
2. تحقق في المخزن (Redis، جدول في قاعدة البيانات) هل ظهر خلال آخر، مثلاً، أربع وعشرين ساعة.
3. إذا ظهر — ردّ على الخدمة بـ «تم الاستلام» ولا ترسل شيئاً إلى الدردشة.
4. إذا لم يظهر — سجّله وعالجه كالمعتاد.

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

إذا جاء التكرار من مصدرين مختلفين

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

هذه التكرارات تختلف عن تكرار الـ webhook في السجلات: للطلبات مصادر مختلفة (منصات مختلفة، معالجات مختلفة)، لكن الحدث الدلالي واحد. ابحث عن تقاطع المُشغّلات وعطّل واحداً منها. بالنسبة للجسر — لا تُعِد إرسال رسائل الروبوت نفسه.

فحص قبل البث

1. أرسل أمراً تجريبياً وانظر كم رداً وصل.
2. عطّل كل التكاملات إلا واحداً، وأعد المحاولة.
3. شغّلها واحداً تلو الآخر حتى يعود التكرار — وهكذا تجد المذنب.
4. قارن في السجلات معرّف الحدث في الردّين: متطابق — إعادة تسليم، مختلف — اشتراك ثانٍ.

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