كيف تمنع النشر المكرر عندما تتأخر استجابة الموقع؟

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

لماذا يحدث التكرار؟

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

هذا هو الفرق بين «لم يصل رد» و«لم تحدث العملية». الصمت لا يعني الفشل.

صمّم مفتاحًا للتعرف على المحاولة

قبل النشر، أعط كل مادة معرفًا داخليًا ثابتًا: مثل تاريخ النشر ومعرف الحملة ورقم المادة. احتفظ به في سجل تشغيل مستقل. بعد إرسال الطلب، ابحث عن المادة باستخدام عنوانها أو معرفها أو تاريخها قبل تكرار الضغط. لو المنصة تدعم مفتاح عدم التكرار (Idempotency Key) عبر API، فهو الخيار الأقوى، لكن لا تفترض توفره في واجهة عادية.

التحقق بالعنوان وحده ليس مثاليًا؛ فقد توجد مواد متشابهة. الأفضل استخدام أكثر من قرينة: العنوان، الكاتب، التوقيت، وجزء مميز من المحتوى.

قرار إعادة المحاولة

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

إذا كنت تستخدم Social Browser لتنفيذ مهمة متكررة، احتفظ بسجل بسيط للمحاولات وتأكد من حالة الصفحة والحساب. تنفيذ Workflow مرتين لا يجعل العملية نفسها آمنة تلقائيًا.

تطبيق على فريق محتوى

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

الخلاصة: لا تُعِد الضغط لأنك لم ترَ استجابة؛ ابحث أولًا عن دليل أن العملية لم تقع.

سؤال: هل تعتبر غياب رسالة التأكيد فشلًا، أم تفضّل حالة ثالثة باسم «غير مؤكدة»؟