Heartbeat و Crash Loop: تصميم مراقبة Browser Worker بدون قتل العمليات السليمة

قتل Browser Worker لمجرد تأخر Heartbeat واحد قد يحول ضغطًا مؤقتًا إلى فقد مهمة سليمة. وفي الاتجاه الآخر، إعادة تشغيل Worker بلا حدود بعد كل crash قد تصنع Crash Loop يستهلك الموارد ويكرر المهام. المراقبة الجيدة تجمع Heartbeat مع Last activity و Lease وعدد restarts، ثم تتخذ القرار على مراحل: degraded، suspected dead، restart، ثم circuit open عند التكرار.

اجعل Heartbeat يعكس حالة حقيقية

Heartbeat يجب أن يحمل أكثر من timestamp: Worker ID، النسخة، عدد المهام الحالية، وربما event loop lag أو آخر خطوة مكتملة. إذا كان Timer منفصلًا تمامًا عن مسار التنفيذ فقد يستمر heartbeat بينما الجزء المسؤول عن المتصفح متجمد. اربط جزءًا من الصحة بمسار العمل أو نفذ فحصًا دوريًا بسيطًا مثل Ping داخلي إلى child process.

استخدم نافذة سماح قبل إعلان الوفاة

حدد interval مثل 10 ثوانٍ و threshold بعد عدة إشارات مفقودة، لا بعد واحدة. عند أول تأخير علّم Worker degraded وأوقف تكليف مهام جديدة، لكن اترك المهمة الحالية إن كان ال ـLease صالحًا. إذا استمر الغياب، نفذ health probe أو IPC ping. فقط بعد فشل أكثر من إشارة انتقل إلى restart.

Crash Loop يحتاج Circuit Breaker

سجل عدد restarts داخل نافذة زمنية، مثل 5 مرات خلال 10 دقائق. بعد تجاوز الحد لا تستمر في restart بنفس السرعة. افتح circuit، اعزل Worker من ال ـpool، وارفع Alert يتضمن آخر exit code ونسخة التطبيق والمهمة التي كانت تعمل. استخدم exponential backoff حتى لا يتحول العطل إلى ضغط إضافي على الخادم.

فرق بين Task failure و Worker failure

Selector مفقود أو HTTP 429 لا يستحق قتل المتصفح كله غالبًا. صنف الخطأ على مستوى Task، Profile، Renderer، أو Worker. Renderer crash قد يتطلب إعادة Tab أو Profile فقط. Worker failure هو آخر مستوى. كلما كان نطاق الاستعادة أقرب إلى موضع الخطأ قل الانقطاع وخطر إعادة تنفيذ أعمال سليمة.