يمكن أن يستقبل المتجر إشعارًا بأن عملية ما اكتملت، ثم يستقبله مرة أخرى لأن الرد الأول لم يصل إلى المزوّد. إذا ربط التطبيق كل وصول بإنشاء طلب أو إرسال شحنة، قد تتكرر النتيجة رغم أن العميل أجرى العملية مرة واحدة. بناء Webhooks موثوق يتطلب فصل وصول الرسالة عن تنفيذ أثرها، مع اختبار حالات الاتصال غير المثالية.
ابدأ من عقد التسليم الخاص بالمزوّد
توضح وثائق Stripe أن تسليم الأحداث قد يتكرر وأن ترتيب وصولها غير مضمون، وتوصي بالتحقق من التوقيع والتعامل مع المعالجة الثقيلة بصورة غير متزامنة. هذه خصائص موثقة لهذا المزوّد وليست عقدًا عامًا لكل خدمة؛ اقرأ وثائق المزوّد الذي تستخدمه وحدّد أنواع الأحداث المطلوبة وما الذي يثبت حالتها.
اكتب جدولًا يربط الحدث بالإجراء المسموح. لا تجعل أي رسالة واردة تغير حالة الطلب مباشرة. حدّد أين يتحقق المصدر والتوقيع، وأين يُسجّل الاستلام بصورة دائمة، وأين تنفذ خطوة العمل. لا تُقرّ استلام رسالة قبل ضمان إمكانية معالجتها لاحقًا إذا كانت خسارتها ستفقد أثرًا مهمًا.
ميّز ثلاثة معرّفات مختلفة
معرّف الحدث يحدد الرسالة التي وصلت. معرّف العملية التجارية يحدد الطلب أو الاشتراك الذي تتغير حالته. أما مفتاح Idempotency في طلب API صادر، فيساعد المزوّد على التعرف إلى إعادة الطلب نفسه. تشرح وثائق Idempotency في Stripe حفظ نتيجة الطلب تحت المفتاح؛ هذا لا يستبدل حماية مستقبِل Webhook من إعادة التسليم.
اختر قيدًا واضحًا يمنع إعادة الأثر نفسه، واحتفظ بحالات الاستلام والانتظار والنجاح والفشل. لا تعتمد فقط على متغير في ذاكرة العامل، لأنه قد يختفي بعد إعادة التشغيل. وحدّد كيف تتعامل مع رسالتين مختلفتين تتصلان بالعملية نفسها دون اعتبار كل واحدة طلبًا جديدًا.
| اختبار في بيئة تجريبية | ما يجب أن تراجعه |
|---|---|
| إرسال الحدث نفسه مرتين | أثر تجاري واحد وسجل استلام واضح |
| توقيع غير صحيح | رفض قبل تعديل حالة الطلب |
| وصول تحديث قبل حدث الإنشاء | عدم الاعتماد على ترتيب مفترض |
| توقف العامل بعد تسجيل الاستلام | استئناف المعالجة دون فقد الرسالة |
| فشل إرسال إشعار للعميل | إعادة الإشعار دون إعادة إنشاء الطلب |
راجع الحالة قبل اتخاذ الإجراء
في سيناريو اختبار افتراضي، تصل رسالة تحديث لطلب قبل وصول الرسالة التي عرف بها التطبيق الطلب لأول مرة. قرر كيف تستعلم عن الحالة المعتمدة أو تؤجل المعالجة، ثم اختبر القرار. لا تستخدم ترتيب الوصول أو وقتًا محليًا وحده لإلغاء حالة تجارية نهائية؛ قواعد التحول يجب أن تكون محددة ومسنودة ببيانات المزوّد.
استخدم طابورًا لمهام العمل التي تحتاج وقتًا، مع سجل لعدد المحاولات والسبب الأخير للفشل. واجهة استلام الإشعار ينبغي أن ترد وفق العقد بعد حفظه بأمان، بينما تكون خطوة التنفيذ قابلة لإعادة المحاولة. افصل إرسال البريد أو تحديث نظام خارجي عن حفظ الحالة الأساسية حتى تعرف أي جزء تعثر.
جهّز طريقة معالجة الأحداث العالقة
راقب الرسائل التي تجاوزت زمن الانتظار المتفق عليه، وضع إجراءً لإعادة المعالجة بموافقة مناسبة وتسجيل أثرها. احتفظ بسجل مفيد للتشخيص دون نسخ بيانات حساسة لا تحتاجها. اختبر إعادة تشغيل العامل وتحديث نسخة الكود مع رسائل معلقة؛ نجاح الاختبار عندما يكون كل شيء متصلًا لا يغطي هذه الحالات.
عند تطوير متجر إلكتروني، أضف هذه الفحوص إلى تسليم التكاملات. وتابع السجل والطابور ضمن الصيانة والدعم. هدف الاختبار أثر واحد صحيح لكل عملية، مع قدرة على التعافي عندما يتكرر الإرسال أو يتغير ترتيبه.
