Crash Loop Detection: متى تعيد التشغيل ومتى توقف المحاولة

الأنظمة المكتبية كثيرًا ما تعيد renderer أو child process بعد crash لتحسين الاستمرارية. المشكلة تبدأ عندما يكون السبب deterministic: ملف تالف أو flag غير متوافق أو extension ينهار عند startup. إعادة التشغيل كل ثانيتين لا تصلح المشكلة؛ هي فقط تنتج logs وضغط CPU وربما تكرر أثرًا. Crash Loop Detection تحتاج window زمنية وتوقيعًا للخطأ وقرارًا واضحًا للانتقال إلى safe state.

عرّف Loop بنافذة زمنية

عدد crashes وحده لا يكفي. ثلاثة crashes خلال دقيقة تختلف عن ثلاثة خلال أسبوع. استخدم rolling window مثل N crashes خلال T minutes، مع counters per component/Profile ID. لا تجعل crash في renderer A يعاقب كل التطبيق إذا بقية النوافذ سليمة.

بصم سبب الانهيار

اجمع signal/exit code وآخر error signature و component version بدون أسرار. إذا تتكرر نفس البصمة بسرعة، ارفع الثقة أن restart لن تساعد. إذا الأسباب مختلفة فقد يكون ضغط موارد أو مشكلة نظام أوسع وتحتاج تحليلًا آخر.

استخدم Backoff وحدًا أقصى

أعد أول مرة سريعًا، ثم زد delay مع jitter. بعد threshold، توقف عن التشغيل التلقائي وانتقل إلى disabled/quarantined state. لا تجعل max attempts يعاد للصفر لمجرد أن process عاشت ثواني؛ اشترط فترة استقرار.

وفر Safe Mode

للمكونات التي يمكن تعطيل ميزاتها، جرّب recovery بدون extension أو restore state أو feature مشتبه بها. Safe Mode يجب أن يكون محدودًا وواضحًا للمستخدم، لا تغييرًا دائمًا مخفيًا. الهدف تمكين الوصول للتشخيص أو البيانات.

احمِ البيانات من restart المتكرر

إذا process تكتب state عند startup ثم تنهار، loop قد تفسد ملفات أو تملأ logs. استخدم atomic writes وحدودًا لحجم السجل. لا تعيد تنفيذ jobs ذات أثر تلقائيًا بعد كل restart دون idempotency.

أبلغ المستخدم بسبب قابل للتنفيذ

بدل اختفاء نافذة ثم عودتها، اعرض أن component توقفت بعد X crashes مع خيار logs أو reset محدود. لا تعرض stack trace خام. إذا البروفايل فقط متأثر، لا تجعل الرسالة تبدو كأن التطبيق كله فشل.

اختبر الحلقة عمدًا

أنشئ build اختبارية أو fixture تجعل component تنهار فور startup. تأكد أن backoff يعمل، threshold يوقف المحاولات، و restart للتطبيق لا يمسح الحماية بطريقة تعيد loop بلا نهاية.

ابنِ Baseline ثم قارن

لتطبيق «Crash Loop Detection: متى تعيد التشغيل ومتى توقف المحاولة» بصورة عملية، ثبت جهاز الاختبار وعدد البروفايلات والنسخة والروابط المستخدمة، ثم خذ baseline قبل أي تغيير. سجّل المتوسط وأيضًا أسوأ الحالات الملحوظة مثل p95 عند توفر عدد كافٍ من العينات. أعد السيناريو بعد تنظيف ما يجب تنظيفه فقط، لأن مسح كل cache قد يصنع اختبارًا غير واقعي. إذا ظهر regression، ضيق النطاق بتغيير متغير واحد: نسخة Electron، إضافة، proxy، أو feature flag. بهذه الطريقة يصبح الأداء أو الاستقرار رقمًا يمكن تفسيره لا مجرد إحساس بأن النسخة أسرع أو أبطأ.

معيار القبول قبل الإغلاق

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