Діагностика завислих задач WooCommerce Action Scheduler

Як зрозуміти, що черга Action Scheduler зависла

Проблема не завжди означає, що всі задачі з минулим часом виконання справді зламані. Частина дій могла бути створена із затримкою або чекати на попередню операцію. Тому спочатку потрібно оцінити стан черги та повторюваність помилки.

У панелі WordPress зазвичай використовується розділ WooCommerce → Статус → Заплановані дії. Там можна переглянути дії зі статусами pending, in-progress, complete, failed і canceled, а також відфільтрувати їх за hook або групою.

Тривожними ознаками є постійне зростання кількості pending, багато failed з однаковим hook, дії, заплановані на минулий час, і повторне створення тієї самої задачі після кожної спроби запуску.

• Перевірте не лише загальну кількість дій, а й найчастіші значення hook.
• Подивіться дату створення, запланований час і останню помилку.
• Порівняйте стан черги через кілька хвилин: якщо кількість pending не змінюється, обробник може не запускатися.
• Не плутайте pending із failed: pending ще очікує запуску, а failed завершилася помилкою.

Перевірка черги через WP-CLI

WP-CLI зручний для сайтів із великою кількістю задач, де адміністративна сторінка завантажується повільно або не показує всю чергу. Команди потрібно виконувати з каталогу WordPress або передати шлях до інсталяції параметром, якщо це налаштовано у вашому середовищі.

Для початкової перевірки достатньо вивести частину pending і failed дій:

• Знайдіть hook, який повторюється у великій кількості записів.
• Зверніть увагу на час виконання: минула дата в pending означає, що дія прострочена, але не обов’язково пошкоджена.
• Перевірте, чи не належать проблемні дії одному плагіну або інтеграції.
• Якщо команда не розпізнається, перевірте наявність і сумісність WP-CLI-команди Action Scheduler у поточному середовищі.

wp action-scheduler list --status=pending --per-page=20
wp action-scheduler list --status=failed --per-page=20

Як знайти першопричину помилок

Найцінніша інформація міститься не в самому статусі failed, а в повідомленні про помилку та контексті конкретного hook. Наприклад, помилка HTTP може вказувати на недоступний API, неправильний ключ або перевищення ліміту запитів. Помилка бази даних — на проблему з таблицями, блокування або нестачу ресурсів.

Відкрийте деталі кількох невдалих дій з однаковим hook і порівняйте тексти помилок. Якщо вони ідентичні, причина зазвичай системна, а не випадкова.

Окремо перевірте журнали WooCommerce та журнал помилок PHP на сервері. У них можуть бути зафіксовані fatal error, тайм-аут, помилка автентифікації або виняток конкретного плагіна. Після ввімкнення журналювання не залишайте надмірний debug-режим активним без потреби на робочому сайті.

• API: перевірте URL, токени, термін дії ключів, SSL-сертифікат, ліміти та відповіді сервісу.
• Плагін: перевірте його останні оновлення, сумісність і чи не створює він одну дію повторно.
• Сервер: перевірте PHP memory limit, максимальний час виконання, доступність бази даних і навантаження.
• Інтеграції: переконайтеся, що endpoint приймає запити та не блокує IP-адресу сервера.
• Замовлення: не повторюйте платіжні дії вручну, доки не зрозуміло, чи не була транзакція вже прийнята платіжною системою.

Перевірка WP-Cron і loopback-запитів

Action Scheduler часто запускається через WP-Cron або внутрішній loopback-запит. Якщо WP-Cron вимкнено, його виклики блокуються хостингом, а сайт не отримує відвідувачів для запуску псевдоcron, черга може накопичуватися навіть за відсутності помилки в коді.

Перевірте системний cron хостингу, налаштування WordPress і результати Site Health. Важливо з’ясувати, чи сервер взагалі може виконати PHP-процес і чи сайт може звернутися сам до себе через HTTP.

Причиною блокування loopback можуть бути Basic Auth на staging-сайті, firewall, WAF, неправильний DNS, SSL-проблеми, обмеження localhost або плагін безпеки. Не вимикайте захисні правила назавжди: спочатку визначте конкретний запит і додайте безпечне виняття, якщо воно потрібне.

• Якщо WP-Cron вимкнено навмисно, налаштуйте системний cron замість повернення випадкових запусків через відвідування.
• Перевірте, чи не запускається кілька незалежних cron-процесів одночасно.
• На staging і production переконайтеся, що cron використовує правильний домен та базу даних.
• Після виправлення перевірте, чи почали переходити нові дії з pending у complete.

Запуск обробки черги через системний cron

Для стабільного запуску краще виконувати Action Scheduler із сервера за розкладом, а не покладатися лише на відкриття сторінок у браузері. Конкретний інтервал залежить від обсягу замовлень, швидкості сервера та плагінів, які створюють дії.

Приклад запису для crontab:

• Замініть /var/www/site на фактичний шлях до WordPress.
• Переконайтеся, що команда wp доступна користувачу, від імені якого працює cron.
• Спочатку запустіть команду вручну та перегляньте результат, а вже потім додавайте її до розкладу.
• Не налаштовуйте надто часті паралельні запуски: це може збільшити навантаження на базу даних і створити конкуренцію між процесами.

*/5 * * * * cd /var/www/site && wp action-scheduler run --quiet

Ручний тест запуску

Перед автоматизацією запустіть обробник вручну в контрольований момент. Якщо він одразу повертає помилку, спочатку виправте її, а не збільшуйте частоту cron.

• Зробіть резервну копію бази даних перед масовою обробкою на проблемному сайті.
• Після запуску повторно перегляньте failed і pending.
• Переконайтеся, що виконання не створює дублікати листів, вебхуків або зовнішніх операцій.

wp action-scheduler run

Що робити із failed і pending діями

Безпечний порядок дій такий: зберегти інформацію про помилку, визначити джерело hook, виправити API, cron, плагін або серверну проблему, а потім повторити обробку. Після виправлення частину failed дій можна запустити повторно, якщо це підтримує ваш сценарій і немає ризику дублювання операції.

Pending-задачі не слід видаляти лише тому, що їх багато. Серед них можуть бути оновлення статусу замовлення, повідомлення клієнту, платіжні вебхуки або синхронізація залишків. Масове видалення здатне залишити замовлення в некоректному стані.

Видалення або очищення доречне лише після перевірки, що дії застарілі, дубльовані, створені видаленим плагіном або більше не мають бізнес-цінності. Для критичних операцій спочатку зафіксуйте ідентифікатори та перевірте результат у зовнішній системі.

• Не видаляйте всю чергу одним кліком без резервної копії та аналізу.
• Не повторюйте платіжні або webhook-дії, якщо не перевірено їхній фактичний статус у сторонньому сервісі.
• Після вимкнення проблемного плагіна переконайтеся, що його старі задачі не залишилися єдиною причиною помилок.
• Для великої черги обробляйте дії поступово й контролюйте навантаження.

Типові помилки під час діагностики

Найчастіша помилка — лікувати симптом, а не джерело. Очищення черги може тимчасово прибрати записи, але якщо плагін продовжує створювати некоректні дії, проблема швидко повернеться.

Ще одна помилка — запускати масову обробку через адміністративну сторінку або браузер. Запит може перерватися через тайм-аут, закриття вкладки чи ліміти PHP. Для великих черг надійнішим є серверний запуск із контрольованим cron.

Також не варто без аналізу оновлювати, вимикати або видаляти плагіни на production. Спочатку зробіть резервну копію, перевірте відтворення на staging і визначте, які дії пов’язані з розширенням.

• Не орієнтуйтеся лише на загальну кількість задач.
• Не вважайте кожну прострочену pending-дію пошкодженою.
• Не запускайте кілька важких воркерів паралельно без контролю ресурсів.
• Не ігноруйте повторюваний hook: він часто прямо вказує на проблемний плагін або інтеграцію.