تصميم Workflow قابل للاستئناف بعد انقطاع الكهرباء أو Crash

Workflow يعيش في الذاكرة فقط ينجح ما دام التطبيق حيًا. عند crash أو انقطاع الكهرباء تضيع معرفة أين وصل وما إذا كانت آخر خطوة نفذت. الاستئناف الحقيقي يتطلب state machine محفوظة بصورة ذرية، checkpoints عند نقاط محسوبة، ومنطق reconciliation للخطوات التي قد تكون نفذت جزئيًا.

حوّل workflow إلى حالات لا قائمة أوامر

عرّف حالات مثل pending و running و waiting_external و completed و failed، ومع كل خطوة سجل input summary و attempt ووقت البداية والنهاية. لا تحفظ DOM snapshot كاملًا كحالة أساسية؛ استخدم identifiers منطقية يمكن إعادة العثور بها على العنصر.

اكتب checkpoint ذرّيًا

اكتب الحالة إلى ملف مؤقت ثم rename أو استخدم transaction في قاعدة البيانات. لا تعدّل عدة ملفات بلا تنسيق، لأن انقطاع الكهرباء قد يتركها غير متوافقة. checkpoint الجيد يمثل نقطة يمكن الرجوع إليها بدون تخمين.

احفظ أقل حالة لازمة

خزن Profile ID و URL المنطقي ومعرف العنصر والنتيجة المطلوبة، لا أسرارًا أو HTML كاملًا إذا لم تكن ضرورية. الجلسة نفسها تبقى في البروفايل. تقليل state يسهل التوافق بين الإصدارات ويحسن الأمان.

نفذ recovery قبل الاستئناف

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

اختبر انقطاعات في نقاط مختلفة

اقتل العملية قبل checkpoint وبعده وأثناء خطوة خارجية. يجب أن ينتج كل سيناريو مسارًا مفهومًا: إعادة تنفيذ آمنة أو reconciliation أو مراجعة بشرية. هذا الاختبار أهم من تشغيل happy path مئة مرة.

صمم خطة Compatibility بين إصدارات ال ـWorkflow

قد يحدث crash ثم يُحدَّث التطبيق قبل استئناف المهمة. عندها checkpoint القديمة قد تشير إلى خطوة تغير اسمها أو شكل بياناتها. أضف workflowVersion و stateVersion وحدد migrations صغيرة من الإصدارات القريبة فقط. إذا كان الفرق كبيرًا، لا تحاول تحويل الحالة تلقائيًا؛ اعرض أن المهمة تحتاج restart من نقطة آمنة أو مراجعة. اختبر أيضًا downgrade إن كان ممكنًا في بيئتك. هذا يمنع استئناف state قديمة بمنطق جديد ينتج action مختلفًا، ويحول التوافق إلى قرار هندسي واضح بدل مجموعة ifs متناثرة داخل كل خطوة.

اختبر الاستئناف مع موارد تغيرت أثناء التوقف

ال ـworkflow قد يتوقف ساعة ثم يعود ليجد أن tab أُغلق، البروفايل انتقل لجهاز آخر، أو السجل الخارجي تغير بواسطة مستخدم. Recovery الجيد لا يعيد إنشاء المشهد القديم بالقوة؛ ينفذ revalidation للموارد الأساسية ويقارن النسخة الحالية بما يتوقعه checkpoint. إذا كان التغير غير مؤثر، يبني context جديدًا ويستمر. إذا مس business state، يتحول إلى reconciliation أو review. اختبر حذف tab وتغيير URL وتعديل العنصر الخارجي أثناء التوقف، وسجل القرار. هذا يمنع الاستئناف من تنفيذ خطوة صحيحة على مورد لم يعد هو نفسه منطقيًا.

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

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