Retry وBackoff في مهام المتصفح الطويلة

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

صنّف الأخطاء قبل قرار الإعادة

Network timeout وHTTP 503 قد يكونان قابلين للمحاولة، بينما Validation error أو Permission denied غالبًا لن يتحسنا بالانتظار. ضع لكل فئة سياسة مختلفة بدل Retry موحد.

استخدم Backoff مع Jitter

بدل 1 ثانية في كل مرة، زِد الانتظار تدريجيًا وأضف Jitter حتى لا تعيد عشرات المهام المحاولة في اللحظة نفسها.

تحقق من الأثر قبل Retry

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

احتفظ بCheckpoint

المهمة الطويلة يجب أن تعود من آخر خطوة مؤكدة بدل البداية. هذا يقلل وقت الاستعادة وخطر تكرار خطوات ناجحة.

سيناريو تطبيقي قبل الاعتماد

تخيل المهمة تعمل عشرات المرات يوميًا، ويحدث في إحدى المرات timeout بعد خطوة لها أثر خارجي. التصميم الجيد يجب أن يعرف أين توقف وما الذي تم بالفعل. في موضوع «Retry وBackoff في مهام المتصفح الطويلة»، نفّذ تجربة صغيرة قبل تعميم القرار. ابدأ بـ1- حدد max attempts.، 2- ابدأ بتأخير قصير.، 3- ضاعف التأخير ضمن حد أقصى.، ثم سجل النتيجة قبل توسيع النطاق. لا تحاول تحسين كل شيء في أول Run؛ المطلوب أولًا إنشاء حالة مرجعية تستطيع العودة إليها ومقارنتها. عندما تنجح التجربة، كررها مرة ثانية بنفس الشروط للتأكد أن النتيجة لم تكن صدفة أو أثر Cache أو حالة مؤقتة.

كيف تقيس نجاح التجربة؟

راقب نسبة النجاح من أول محاولة، عدد retries، زمن كل خطوة، عدد التدخلات اليدوية، وحالات التكرار أو الـloop. هذه المقاييس أهم من مجرد انتهاء Run واحدة بنجاح. حوّل النقاط الموجودة في المقال إلى مؤشرات قابلة للرصد: 4xx ليست كلها غير قابلة للإعادة.؛ Timeout قد يحدث بعد تنفيذ الأثر.؛ Selector missing قد يكون transient أو تغيير واجهة دائم.. احتفظ بالقياسات مع timestamp ونسخة التطبيق أو البيئة، لأن مقارنة أرقام من إصدارات أو شروط مختلفة قد تعطي استنتاجًا خاطئًا. وإذا كانت النتيجة رقمية، استخدم أكثر من عينة بدل أفضل أو أسوأ قيمة منفردة.

عند الفشل: ماذا تراجع أولًا؟

عند الفشل، لا تبدأ من أول Workflow تلقائيًا. تحقق من آخر checkpoint والأثر الخارجي، ثم اختر retry أو resume أو manual review وفق حالة مؤكدة. عند التحقيق استخدم هذه القائمة كحد أدنى: الخطأ مصنف.؛ المحاولات محدودة.؛ الأثر الخارجي قابل للتحقق.؛ الـBackoff مسجل.. سجل ما الذي جربته وما الذي لم يتغير بعد التجربة. هذه المعلومة تمنع الفريق من إعادة نفس المحاولات وتساعد على تحديد ما إذا كان الخطأ في الإعداد أو الأداة أو الشبكة أو بيانات المهمة.

متى تعتمد القرار على نطاق أوسع؟

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