إصلاح Action Scheduler في WooCommerce: معالجة المهام العالقة بأمان

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

القاعدة الآمنة هي: التقط نسخة احتياطية، وحدد الـhook المتعطل، واقرأ سجل الخطأ، وعالج السبب، ثم شغّل مجموعة صغيرة للاختبار. يشرح هذا الدليل إصلاح Action Scheduler في WooCommerce بطريقة قابلة للقياس مع خطة رجوع واضحة، ويبين الفرق بين مشكلة في الطابور ومشكلة أعمق في WP-Cron في ووردبريس أو الخادم.

ما هو Action Scheduler ولماذا يعتمد عليه WooCommerce؟

Action Scheduler هو نظام Job Queue مفتوح المصدر يعمل داخل WordPress. يخزن اسم الإجراء وموعده ومعاملاته، ثم يشغله لاحقًا ويسجل مراحل الإنشاء والبدء والاكتمال والفشل. يعتمد افتراضيًا على WP-Cron وطلبات loopback، لكنه يضيف تتبعًا وسجلًا أفضل من جدولة WordPress التقليدية. لذلك فإن إصلاح Action Scheduler في WooCommerce يتطلب فحص النظامين معًا بدل التركيز على شاشة Scheduled Actions وحدها.

يمكن الوصول إلى الطابور من WooCommerce ← الحالة ← الإجراءات المجدولة. راقب تبويبات Pending وIn-progress وFailed وComplete، ثم صفِّ النتائج حسب الـhook أو المجموعة. وجود بضع مهام Pending بموعد مستقبلي طبيعي؛ الخطر هو ازدياد العدد بمرور الوقت أو تكرار الخطأ نفسه في مئات السجلات.

علامات تؤكد أن المشكلة في الطابور

• زيادة عدد Pending Actions كل ساعة بدل انخفاضه.
• تأخر Webhooks أو رسائل الطلبات رغم اكتمال الطلب.
• وجود Failed Actions تحمل الـhook ورسالة الخطأ نفسيهما.
• بقاء مهام In-progress مدة أطول بكثير من زمنها المعتاد.
• ظهور Missed Schedule بالتزامن مع فشل مهام WooCommerce.
• تضخم جدولي actionscheduler_actions وactionscheduler_logs.

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

الخطوة الأولى: خذ خط أساس قبل أي تعديل

سجل عدد المهام في كل حالة، وأكثر خمسة hooks تكرارًا، وأقدم مهمة Pending، ومساحة جداول Action Scheduler. التقط نسخة من سجلات WooCommerce ← الحالة ← السجلات وابحث عن fatal error أو memory exhausted أو timeout. وإذا كان المتجر يستقبل طلبات حقيقية، نفّذ الاختبار في وقت منخفض الحركة واتبع منهج صيانة ووردبريس الآمنة.

قبل إصلاح Action Scheduler في WooCommerce أنشئ نسخة احتياطية لقاعدة البيانات تحديدًا. قد يحتوي الطابور على مدفوعات أو مزامنة طلبات؛ حذف الصفوف مباشرة من MySQL قد يقطع العلاقة بين المهمة والسجل أو يسبب تنفيذًا مزدوجًا بعد أن تعيد الإضافة إنشاءها.

الخطوة الثانية: افحص الـhook والسجل

افتح مهمة Failed واقرأ Log Entries من الأقدم إلى الأحدث. ابحث عن اسم الإضافة، وHTTP status، ونص الاستثناء، ورقم الطلب أو المنتج، ومدة التنفيذ. إذا كان الخطأ 401 أو 403 فالمشكلة غالبًا مصادقة أو Firewall. وإذا كان 429 فهناك Rate Limit. أما ظهور database connection أو memory exhausted فيوجه التحقيق إلى الخادم وقاعدة البيانات.

عند تكرار hook واحد، أوقف فقط الوظيفة التي تولده إن أمكن، ثم اختبر نسخة الإضافة والتوافق. يفيد هنا تطبيق خطوات تشخيص تعارض الإضافات. الهدف من إصلاح Action Scheduler في WooCommerce هو إزالة السبب المنتج للفشل قبل إعادة المحاولة.

الخطوة الثالثة: تحقق من WP-Cron وطلبات loopback

يشغّل نظام المهام الـRunner افتراضيًا عبر WP-Cron كل دقيقة، كما قد يبدأ طلبًا غير متزامنًا عند إنهاء طلبات لوحة التحكم. إذا كان DISABLE_WP_CRON مفعّلًا دون cron حقيقي، أو كانت طلبات loopback محجوبة بواسطة Basic Auth أو WAF، فلن يتحرك الطابور بانتظام.

1. افتح أدوات ← صحة الموقع وابحث عن خطأ loopback.
2. راجع wp-config.php بحثًا عن DISABLE_WP_CRON.
3. إذا كان WP-Cron معطلًا، تحقق من وجود cron على مستوى الخادم.
4. اختبر تنفيذ مهمة واحدة يدويًا من Scheduled Actions.
5. راقب هل انخفض Pending خلال عشر دقائق.

إذا كانت كل المهام المجدولة متأخرة فالمشكلة عامة في cron أو الخادم. أما إذا كان التأخير محصورًا في hook واحد، فالأقرب أن callback نفسه يفشل. هذه التفرقة تختصر وقت إصلاح Action Scheduler في WooCommerce بصورة كبيرة، وتمنع إجراء تعديلات غير لازمة على المتجر.

الخطوة الرابعة: شغّل دفعة صغيرة وراقب الأثر

لا تستخدم Run لكل المهام دفعة واحدة في متجر مزدحم. اختر مهمة قديمة واحدة من hook معروف، وشغّلها، ثم تحقق من الطلب أو التكامل المرتبط بها. بعد نجاحها شغّل خمسًا إلى عشر مهام وراقب CPU وPHP workers وزمن الاستجابة. إذا بدأ الخادم بإرجاع 502 أو 504 فأوقف الزيادة وعد إلى التشخيص.

المعالجة الافتراضية محافظة: دفعات صغيرة وحد زمني قصير لتعمل على استضافات مختلفة. رفع batch size أو time limit قد يسرّع إصلاح Action Scheduler في WooCommerce لكنه قد يستهلك الذاكرة أو يحتجز PHP workers. لا تطبق فلترًا دائمًا قبل قياس متوسط زمن المهمة وحد الذاكرة المتاح.

تشغيل الطابور عبر WP-CLI

في المتاجر الكبيرة يكون WP-CLI أكثر ثباتًا لأنه لا يخضع لقيود طلبات الويب. ابدأ بعرض التعليمات والحالة قبل التنفيذ، ثم عالج مجموعة محددة. تختلف الأوامر المتاحة حسب النسخة المدمجة من Action Scheduler، لذلك لا تنسخ أمر حذف أو تنظيف قبل التحقق منه في بيئتك.

wp action-scheduler help
wp action-scheduler status
wp action-scheduler run --batch-size=25 --batches=1

سجّل المخرجات وقارن عدد Pending قبل التنفيذ وبعده. إذا لم تتحرك القائمة رغم نجاح الأمر، فراجع callback نفسه أو الاتصال بالخدمة الخارجية. وإذا تحركت عبر CLI فقط، فالمشكلة في Runner المبني على طلبات الويب.

متى تنظف جداول Action Scheduler؟

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

بعد معالجة السبب يمكن تنظيف السجلات القديمة تدريجيًا مع نسخة احتياطية. راجع أيضًا دليل Object Cache في ووردبريس إذا كان التنفيذ يتأثر بطبقة كاش مستمرة. نجاح إصلاح Action Scheduler في WooCommerce يقاس بعدم عودة التراكم خلال 24 إلى 72 ساعة.

أسباب شائعة وحلولها

خطة تحقق بعد الإصلاح

1. قارن عدد Pending الآن وبعد 15 و60 دقيقة.
2. تأكد أن أقدم مهمة تتحرك وأن Failed لا يزيد.
3. نفّذ طلبًا تجريبيًا وراقب البريد والمخزون والWebhook.
4. راجع WooCommerce logs وPHP error log.
5. راقب زمن لوحة التحكم واستهلاك قاعدة البيانات.
6. كرر القياس في وقت ذروة حقيقي.

إذا انخفض الطابور مؤقتًا ثم عاد، فالإصلاح لم يكتمل. ابحث عن معدل إنتاج مهام أعلى من قدرة التنفيذ، أو callback يضيف نسخة جديدة عند كل فشل. هنا يتحول إصلاح Action Scheduler في WooCommerce من تشغيل يدوي إلى تحسين منطق المهمة أو نقل الطوابير الكبيرة إلى WP-CLI وcron مخصص. ويمكن مقارنة النتائج مع مشاكل WooCommerce الشائعة لاستبعاد أعطال الطلبات والمخزون.

سيناريو عملي لتشخيص الطابور خلال 30 دقيقة

افترض أن المتجر يملك 2400 مهمة Pending و300 مهمة Failed، وأن رسائل الشحن تصل بعد ساعات. في أول خمس دقائق لا تشغّل شيئًا؛ صفِّ المهام حسب أقدم تاريخ وسجّل أكثر hooks تكرارًا. إذا كان Action Scheduler يعرض hook واحدًا مسؤولًا عن معظم الفشل، افتح ثلاث مهام منه وقارن رسائل السجل بدل الاعتماد على عينة واحدة.

في الدقائق الخمس التالية افحص WP-Cron وSite Health وloopback. إذا كانت بقية مهام Action Scheduler تتقدم بينما hook الشحن وحده يفشل، فـWP-Cron ليس السبب الأساسي. انتقل إلى اتصال مزود الشحن، وافحص DNS وTLS والمصادقة وHTTP status وزمن الاستجابة.

من الدقيقة 10 إلى 20 شغّل مهمة واحدة يدويًا مع مراقبة سجل WooCommerce وPHP. إذا نجحت، شغّل دفعة صغيرة. وإذا فشلت برسالة 429، لا تكرر Run؛ طبّق backoff وقلل التزامن. وإذا فشلت بـ500، التقط stack trace وحدد الإضافة. يمنع هذا الأسلوب Action Scheduler من مضاعفة الطلبات على خدمة خارجية متعبة أصلًا.

في آخر عشر دقائق قارن Pending قبل الاختبار وبعده، وسجل متوسط زمن المهمة، ثم قرر: إصلاح الاتصال، تحديث الإضافة، تعديل cron، أو استخدام WP-CLI. القرار يجب أن يرتبط بالدليل. إعادة تشغيل Action Scheduler دون معالجة السبب قد تخفي العطل لدقائق فقط.

مؤشرات مراقبة Action Scheduler في المتاجر الكبيرة

لا تنتظر شكوى العميل لاكتشاف التأخير. أنشئ لوحة مراقبة بسيطة تسجل عدد Pending وFailed، وعمر أقدم مهمة، ومعدل التنفيذ في الساعة. أضف تنبيهًا إذا تجاوزت أقدم مهمة حدًا مناسبًا لنشاط المتجر؛ خمس دقائق قد تكون خطرة لدفعات الاشتراك، بينما ساعة قد تكون مقبولة لتقرير غير عاجل.

• Queue depth: عدد المهام المنتظرة الآن.
• Queue age: عمر أقدم مهمة مستحقة.
• Failure ratio: نسبة Failed إلى المهام المنفذة.
• Throughput: عدد المهام المكتملة في الساعة.
• Execution time: وسيط و95th percentile لزمن المهمة.
• Top failing hooks: أكثر callbacks تكرارًا في الفشل.

يساعد تتبع هذه المؤشرات على اكتشاف ما إذا كان Action Scheduler يتباطأ تدريجيًا بسبب نمو المتجر أو يتعطل فجأة بعد تحديث. اربط وقت بداية المشكلة بعمليات النشر وتحديث الإضافات وتغيرات الاستضافة.

متى تنقل التنفيذ من Web Runner إلى WP-CLI؟

يناسب Web Runner معظم المتاجر الصغيرة والمتوسطة. أما الطوابير الكبيرة أو المهام طويلة التنفيذ فتستفيد من WP-CLI لأنه لا يمر عبر timeout الخاص بطلب HTTP ولا ينافس زوار الواجهة بالطريقة نفسها. النقل مفيد عندما يعمل Action Scheduler جيدًا يدويًا عبر CLI لكنه يتوقف عبر loopback، أو عندما يقترب كل batch من حد الذاكرة والوقت.

لا تجعل cron يشغل عدة نسخ متزامنة بلا قفل، ولا تستخدم عددًا كبيرًا من concurrent batches على خادم محدود. ابدأ بعملية واحدة، وقس throughput وCPU وI/O، ثم زد تدريجيًا. إذا كان callback نفسه بطيئًا، رفع التزامن قد ينقل الاختناق إلى MySQL أو API الخارجي.

قائمة منع تكرار المشكلة

1. راقب Action Scheduler بعد تحديث WooCommerce والإضافات الحساسة.
2. لا تسمح لإضافة بإنتاج مهام أسرع من قدرة الخادم على تنفيذها.
3. استخدم idempotency في التكاملات حتى لا تسبب إعادة المحاولة تنفيذًا مزدوجًا.
4. ضع timeouts واضحة لاتصالات API وسجل response body الآمن.
5. جدول المهام الثقيلة خارج أوقات الذروة.
6. نظف Completed القديمة وفق السياسة الافتراضية أو سياسة موثقة.
7. اختبر WP-Cron وloopback ضمن المراقبة الدورية.

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

أسئلة شائعة

هل حذف Failed Actions آمن؟

ليس قبل قراءة السجل وفهم وظيفة الـhook. قد تمثل المهمة دفعة أو رسالة أو مزامنة طلب. أصلح السبب ثم أعد التشغيل أو ألغ المهمة وفق توثيق الإضافة.

لماذا تعود المهام بعد حذفها؟

لأن الإضافة المالكة تعيد جدولتها عند كل طلب أو cron. الحذف يعالج العرض وليس المصدر.

هل Action Scheduler بديل كامل لـWP-Cron؟

لا. هو طابور أكثر قابلية للتتبع، لكنه يعتمد افتراضيًا على WP-Cron وطلبات loopback لبدء Runner.

هل رفع batch size يحل البطء؟

قد يزيد السرعة على خادم مناسب، لكنه قد يرفع الذاكرة ويستهلك workers. ابدأ بدفعة صغيرة وقس.

ما أفضل مؤشر على نجاح الإصلاح؟

انخفاض Pending باستمرار، وثبات Failed، ووصول الأحداث المرتبطة إلى وجهتها ضمن الزمن المتوقع.

مصادر موثوقة

• الوثائق الرسمية لـAction Scheduler
• معالجة الطوابير الكبيرة والأداء
• تشغيل Action Scheduler عبر WP-CLI

الخلاصة: إصلاح Action Scheduler في WooCommerce ليس زر Run جماعيًا. ابدأ بالسجل والـhook، وأصلح WP-Cron أو callback، واختبر دفعات محدودة، ثم راقب الطابور يومين على الأقل. بهذه الطريقة تحمي الطلبات والمدفوعات من التنفيذ المكرر أو الفقد.