هل حفظ ذلك الإرسال الذي انتهت مهلته عملك فعلاً؟

يدور الزر، ويظهر في التبويب خطأ، ويضيع النموذج الذي أمضيت عشر دقائق في تعبئته. ما لا تعرفه هو هل وصلت الكتابة قبل أن ينقطع الاتصال. التعامل مع هذا المجهول كأنه فشل هو الطريقة التي تُنشأ بها التعليقات المكررة والطلبات المزدوجة وتذاكر الدعم المتكررة.

استعد بالترتيب الثابت: احتفظ بالنص، واعثر على النتيجة، وحينها فقط قرر هل يُسمح بإرسال ثانٍ.

ابدأ بالنص وختم الوقت

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

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

ابحث عن النتيجة في عرض التطبيق نفسه

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

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

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

قرر ما إذا كانت إعادة الإرسال آمنة

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

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

curl -i -X POST https://api.example.net/v1/orders \
  -H "Idempotency-Key: 6f1c2a94-3b7e-4a10-9c22-5d0e8f7b1a63" \
  -H "Content-Type: application/json" \
  --data @order.json

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

اجمع الأدلة قبل أن تضغط أي شيء مرة أخرى

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

اسأل مالك الخدمة سؤالاً واحداً محدداً: هل نجحت العملية بهذا المحتوى في هذا الوقت، وهل يوجد مرجع لها؟ هذا السؤال له جواب، أما "هل تعطل الموقع" فليس له جواب.

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