كيف تبني Retry Policy مختلفة للنقر والتحميل وطلبات API

Retry click و retry navigation و retry API request ليست العملية نفسها. Navigation قد تكون read-only، click قد يرسل نموذجًا، و API قد يدعم idempotency key. لذلك policy واحدة من ثلاث محاولات لكل خطأ تبسط الكود لكنها تخلق أخطاء منطقية. الأفضل تصنيف الخطوات حسب الأثر ونوع الفشل.

النقر: تحقق من الأثر قبل التكرار

إذا كان النقر يفتح tab يمكن تكراره غالبًا بعد فحص عدم فتحها. أما زر submit أو delete فيحتاج result check. استخدم selector state و business outcome بدل مجرد غياب response event.

التحميل والتنقل: فرق الأخطاء

net::ERR_NAME_NOT_RESOLVED لا يشبه 503. DNS failure قد يحتاج فحص شبكة، 503 قد يستفيد من backoff، و 404 غالبًا permanent. صنف error codes بدل retry أي navigation failure.

API: استخدم semantics البروتوكول

GET غالبًا آمن للتكرار، POST ليس بالضرورة. اقرأ Retry-After في 429 أو 503، واستخدم idempotency keys إذا يوفرها API. لا تفترض أن timeout يعني أن الخادم لم ينفذ الطلب.

ضع budget للمهمة كلها

خمس retries كل منها 30 ثانية قد تتجاوز موعد المهمة. عرف deadline إجماليًا ووزع attempts داخله. إذا لم يبق وقت كافٍ لتنفيذ آمن، انقل job إلى failure أو مراجعة بدل محاولة أخيرة يائسة.

أضف jitter للتزامن

عندما يفشل مزود خارجي، آلاف jobs قد تعيد المحاولة في نفس الثانية. exponential backoff مع jitter يقلل thundering herd. استخدم حدودًا معقولة حتى لا تتحول المهمة إلى انتظار ساعات بلا visibility.

اختبر Retry Policy بأخطاء مركبة

الأنظمة الحقيقية لا تفشل بنوع واحد. أنشئ test sequence: DNS failure في المحاولة الأولى، 503 في الثانية، ثم success؛ وسيناريو آخر فيه timeout بعد submit. تحقق أن policy تغير التصنيف ولا تستمر بنفس backoff بلا فهم. سجل retry reason لكل attempt واحسب هل deadline ما زال يسمح بمحاولة مفيدة. اختبر أيضًا أن error permanent يوقف فورًا حتى لو بقيت attempts. هذه الاختبارات تمنع policy تبدو صحيحة لكل error منفرد لكنها تتصرف بشكل سيئ عندما يتغير السبب بين المحاولات.

ضع حدودًا لل ـRetry على مستوى المورد

حتى لو كل job تسمح بثلاث محاولات، مئة job على نفس حساب أو domain قد تنتج 300 محاولة أثناء outage. أضف circuit breaker أو rate limit مشتركًا حسب resource. عندما ترتفع الأخطاء على domain معين، أوقف retries الجديدة لفترة واستخدم half-open probes قليلة قبل العودة. هذا يقلل الضغط على خدمة متعثرة ويحمي الحسابات من نشاط غير طبيعي. سجل سبب فتح circuit ووقت الإغلاق حتى يفهم المشغل لماذا jobs متوقفة رغم بقاء attempts لها.

حوّل الفكرة إلى سيناريو قابل للإعادة

لتقييم «كيف تبني Retry Policy مختلفة للنقر والتحميل وطلبات API» اكتب workflow صغيرًا له بداية معروفة ونهاية قابلة للقياس، ثم اختبر happy path وحالة timeout وحالة إعادة التشغيل. يجب أن يكون واضحًا ما إذا كانت الخطوة قابلة للتكرار بأمان، وما الذي يحدث إذا نُفذت مرتين، وأين تحفظ حالة التقدم. بعد ذلك شغّل السيناريو على بيانات اختبار لا على حساب إنتاجي، وسجّل سبب كل retry والوقت المستغرق. هذه التفاصيل تمنع نجاحًا ظاهريًا في أول تشغيل ثم فشلًا صعب التفسير عندما تعمل المهام بالتوازي أو تستأنف بعد crash.