متى يستحق التنفيذ المتين التعقيد الإضافي؟ خمسة سيناريوهات عملية مع Durable Task

لا تكمن قيمة Durable Task في استبدال كل عامل خلفي أو طابور رسائل أو قاعدة بيانات، بل في تنظيم العمليات التي تمتد طويلاً، وتتوقف بانتظار حدث خارجي، أو قد تنقطع بعد تنفيذ جزء من خطواتها. وتعرض مدونة .NET خمسة أمثلة عملية باستخدام حزمة Durable Task .NET SDK الإصدار 1.26.0 مع Durable Task Scheduler، مع التشديد على أن الأداة تحفظ تاريخ التنسيق ولا تستعيد مكدس تنفيذ CLR المعلّق.

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

الموافقة البشرية لا تعني إيقاف العامل

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

مع ذلك، يكون حدث الموافقة مجرد إشارة. يجب على نقطة نهاية موثقة أن تسجل القرار النهائي بشكل ذري في مخزن التطبيق قبل إرسال الإشارة، وأن تتحقق خطوة المحاسبة من هوية نشر ثابتة وبصمة طلب غير قابلة للتغيير. فإذا قُبل القيد المحاسبي ثم فُقد تأكيد النشاط، فلا يكفي تاريخ Durable Task لمنع التكرار؛ بل يلزم بروتوكول مصالحة مع النظام المحاسبي.

تهيئة بيئة Azure: أين ينتهي دور ARM؟

توضح المادة أن ARM وBicep قد يكونان كافيين لنشر موارد محددة، إذ يقدمان ترتيب الاعتماديات، والتنفيذ المتوازي، وإعادة تطبيق الحالة المطلوبة بهويات ثابتة. لذلك لا تستحق إضافة Durable Task إعادة بناء مخطط نشر توفره ARM أصلاً.

تظهر الفائدة عندما يتجاوز المسار نشر الموارد إلى قبول طلب المستأجر، وإبلاغه بالتقدم، وانتظار الجاهزية، ثم تفعيل المستأجر. يقترح المثال حفظ طلب التهيئة ومعرّفاته في قاعدة التطبيق مع outbox، ثم استخدام تنسيق يربط مراحل الشبكة وقاعدة البيانات والتخزين والتطبيق وDNS وفحص الجاهزية. أما عمليات Azure نفسها فتظل بحاجة إلى سجلات عمليات وهويات ثابتة ومصالحة عند فقدان الردود.

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

انتهاء مهلة الدفع ليس رفضاً

في دورة الاشتراك، قد يختفي رد مزود الدفع بعد قبول العملية. إعادة المحاولة فوراً قد تفرض رسماً مزدوجاً، بينما اعتبارها مرفوضة قد يرسل تنبيهاً مضللاً. يقترح المثال ربط كل دورة دفع بمعرّف دورة ومفتاح دفع ثابت، ثم استخدام مؤقتات durable، واستدعاءات رجعية، وفحوص دورية، ومهلة سماح محددة.

يبقى دفتر المدفوعات هو المرجع authoritative للحالات Unknown وPending وDeclined وPaid وNotCharged. ولا تنتقل الدورة إلى التالية إلا بعد تأكيد الإيصال وإغلاق الدورة الحالية. وإذا انتهت المهلة مع بقاء الحالة غير محسومة، تكون النتيجة NeedsReconciliation بدلاً من افتراض نجاح الدفع أو فشله.

الأحداث المتأخرة تحتاج حماية في الوجهة

في تحديث فهرس بحث لمقالات إخبارية، قد يصل الإصدار 12 بعد الإصدار 13 أو تنتهي عمليات الفهرسة بترتيب معاكس. يستطيع الكيان durable حفظ أعلى إصدار تمت رؤيته وتسلسل تحديث عداداته، لكنه لا يقفل الفهرس الخارجي ولا يمنع طلبين من الكتابة بالتوازي.

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

ما الذي يعنيه ذلك لوكلاء الذكاء الاصطناعي؟

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

الاستنتاج العملي من الأمثلة الخمسة هو أن Durable Task مناسب عندما يصبح حفظ «ما الذي سيحدث تالياً» نظاماً بحد ذاته. أما إذا كان التطبيق يملك بالفعل طوابير ومؤقتات وسجلات مصالحة واضحة، أو إذا كان النظام الخارجي يوفر تنسيقاً موثوقاً مثل ARM، فقد يضيف الإطار طبقة تعقيد أكثر من قيمة. كما أن جميع الأمثلة تعتمد على حدود خارجية صريحة: سجل سلطوي، مفتاح idempotency، حاجز إصدار، outbox، أو بروتوكول مصالحة.