أي Workflow طويل سيتعرض يومًا ل timeout أو crash أو إعادة تشغيل. إذا كانت كل إعادة محاولة تعيد تنفيذ آخر خطوة بلا معرفة ما إذا نجحت سابقًا، فقد يرسل النظام نموذجًا مرتين أو ينشئ عنصرًا مكررًا. Idempotency ليست مفهوم API فقط؛ يمكن تصميمها حول خطوات المتصفح من خلال مفاتيح حالة وفحوص قبل التنفيذ.
حدد الخطوات ذات الأثر
قسّم workflow إلى قراءات وإجراءات تغير الحالة. الانتقال لصفحة أو قراءة نص يمكن تكراره غالبًا، بينما إرسال طلب أو حذف عنصر أو اعتماد عملية يحتاج حماية. اكتب لكل خطوة أثرها المتوقع ومؤشرًا يمكن التحقق منه بعد التنفيذ.
استخدم مفتاح عملية ثابتًا
إذا كان النظام المستهدف يدعم idempotency key فاستخدمه. في واجهات الويب التي لا تدعمه، أنشئ معرفًا داخليًا للعملية واربطه ببيانات مثل account و workflow و business item. قبل إعادة التنفيذ، ابحث عن دليل نجاح مرتبط بنفس المفتاح.
خطوات عملية
- أنشئ operation ID قبل الخطوة.
- احفظه في checkpoint.
- نفذ الإجراء مرة.
- تحقق من النتيجة قبل أي retry.
افصل unknown عن failed
Timeout بعد submit لا يعني فشلًا؛ قد يكون الخادم نفذ العملية ثم انقطع الرد. هذه حالة unknown وتحتاج reconciliation لا retry مباشر. افتح صفحة النتيجة أو استخدم API قراءة لتحديد ما حدث.
قائمة مراجعة
- failed مؤكد.
- success مؤكد.
- unknown يحتاج تحقق.
- لا تحول unknown إلى retry تلقائي.
صمم إعادة التشغيل من حدود آمنة
بعد crash، استأنف من آخر checkpoint مستقر لا من آخر event في log فقط. إذا كانت الخطوة ذات أثر وتوجد نتيجة محتملة، نفذ read-before-write. هذا يبطئ جزءًا صغيرًا لكنه يمنع مضاعفة الأثر.
اختبر idempotency عمدًا
شغّل fault injection بعد النقر مباشرة وقبل قراءة النتيجة، ثم أعد workflow. كرر السيناريو مع network timeout. نجاح الاختبار يعني بقاء أثر واحد فقط مع log يشرح كيف تم التعرف على التنفيذ السابق.
اختبر السيناريو الأصعب: نجاح خارجي مع فشل محلي
أخطر حالة في idempotency هي أن ينجح النظام الخارجي ثم يفشل المتصفح قبل أن يسجل النجاح محليًا. صمم تجربة تضغط submit ثم تقتل renderer قبل وصول confirmation. عند restart يجب ألا يعيد workflow الإرسال مباشرة؛ يبدأ reconciliation عبر البحث عن العملية باستخدام business key أو timestamp ونطاق المستخدم. إذا وجد أثرًا واحدًا مطابقًا، يسجل success ويكمل. إذا وجد أكثر من أثر، يوقف المهمة ويصعّد للمراجعة. وإذا لم يجد شيئًا، يسمح بمحاولة جديدة مع نفس operation ID عندما يدعم النظام ذلك. هذه الحالة تكشف الفرق بين retry عادي وتصميم idempotent حقيقي، لأنها تجبر النظام على التعامل مع الغموض بدل افتراض الفشل.
قائمة مراجعة
- Fault بعد الإرسال وقبل confirmation.
- بحث read-only عن الأثر.
- لا retry قبل حسم unknown.
- تسجيل reconciliation decision.
حوّل الفكرة إلى سيناريو قابل للإعادة
لتقييم «Idempotency في أتمتة المتصفح: كيف تمنع تنفيذ الإجراء مرتين» اكتب workflow صغيرًا له بداية معروفة ونهاية قابلة للقياس، ثم اختبر happy path وحالة timeout وحالة إعادة التشغيل. يجب أن يكون واضحًا ما إذا كانت الخطوة قابلة للتكرار بأمان، وما الذي يحدث إذا نُفذت مرتين، وأين تحفظ حالة التقدم. بعد ذلك شغّل السيناريو على بيانات اختبار لا على حساب إنتاجي، وسجّل سبب كل retry والوقت المستغرق. هذه التفاصيل تمنع نجاحًا ظاهريًا في أول تشغيل ثم فشلًا صعب التفسير عندما تعمل المهام بالتوازي أو تستأنف بعد crash.
قائمة مراجعة
- بداية ونهاية واضحتان.
- Retry محدود ومسبب.
- اختبار تنفيذ الخطوة مرتين.
- استعادة بعد restart أو crash.
شارك في تقييم ونقاش المقال
رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.
النقاش
جارٍ تحميل التعليقات…