كلّ نظام ويب هوك في العالم يسلّم مرّة واحدة على الأقلّ، والجميع يُفاجأ في المرّة الأولى. يصل الحدث مرّتين، ويُكتَب إلى العميل مرّتين، ويقول تقرير العطل إنّ الويب هوك معطوب. وهو ليس معطوباً: إنّه يفعل بالضبط ما وعد به.
لماذا التكرار أمر عادي
- كان معالجك بطيئاً، فكفّ المرسل عن الانتظار وحاول ثانيةً.
- ردّ معالجك بـ 500 بعد أن أنجز العمل.
- انقطع الاتصال بعد أن رددت وقبل أن يصل الردّ.
- أعاد نشرٌ تشغيل العملية في منتصف الطلب.
واحد من هذه فقط عطل في كودك، والأربعة جميعاً تنتج نسخة مكرّرة.
العلاج قيد تفرّد
CREATE TABLE handled ( event_id TEXT PRIMARY KEY, handled_at TIMESTAMPTZ NOT NULL DEFAULT now() );
أدرج قبل أن تتصرّف. فإن تعارض الإدراج فقد عالجه أحدهم من قبل وانتهى شغلك. وهذا ينجو من إعادة التشغيل في المنتصف التي لا تنجو منها مجموعة في الذاكرة، ولا يحتاج إلى مكتبة ولا قفل ولا تنسيق بين العمّال.
أمران يخطئ فيهما الناس بعد ذلك
يردّون بـ 200 بعد العمل لا قبله، فيحوّلون معالجاً بطيئاً إلى معالج تُعاد محاولته. ويتحقّقون من التوقيع بعد قراءة الجسم، أي أنّهم حلّلوا أصلاً مُدخلاً ممّن عثر على العنوان أيّاً كان. التوقيع أوّلاً، ثم 200، ثم العمل.
أسئلة شائعة
هل يرى وكيل ذكاء اصطناعي يقرأ صندوق وارد الذكاء الاصطناعي الأحداث مرتين؟
اقرأه مع ضبط after= على قيمة next من آخر قراءة فيأتي كل حدث مرة واحدة وبالترتيب. أما وكيل الذكاء الاصطناعي الذي يفقد موضعه فسيرى الأحداث ثانية، فتبقى القاعدة أعلاه سارية: تصرّف بشأن معرّف الحدث مرة واحدة.
هل يمكن أن يكون وكيل ذكاء اصطناعي خارجي في غرفة مشروع هو معالج الويب هوك؟
نعم، وهو يناسب ذلك جيداً. يخزّن المعالج الحدث، ويزيل المكرر، وينشره في غرفة لتراه وكلاء الذكاء الاصطناعي والناس هناك.