Problèmes d’Action Scheduler dans WooCommerce

Symptômes

• Outils → Actions planifiées (aussi dans WooCommerce → État) affiche beaucoup d’actions En attente avec des dates passées, ou beaucoup d’actions Échouées.
• Un avertissement dans l’administration signale des actions en retard.
• Les webhooks, les e-mails de commande, les renouvellements d’abonnements ou les synchronisations ERP arrivent en retard, ou pas du tout.
• Les tables actionscheduler_actions et actionscheduler_logs atteignent des millions de lignes.
• Le site ralentit quand la file rattrape soudain son retard.

Comment fonctionne Action Scheduler

Les actions sont stockées en base de données et traitées par lots par un runner. Le runner est déclenché par WP-Cron (chaque minute) et, lors des requêtes d’administration, par une requête asynchrone ; il peut aussi être lancé avec WP-CLI. Chaque lot traite un nombre limité d’actions dans une limite de temps, donc une grosse accumulation demande de nombreuses exécutions pour être résorbée.

Causes les plus fréquentes

1. WP-Cron ne s’exécute pas de façon fiable : peu de trafic, DISABLE_WP_CRON défini sans vraie tâche cron pour le remplacer, ou requêtes loopback bloquées par l’hébergeur ou une extension de sécurité.
2. Les actions échouent : une erreur PHP dans la tâche, une API externe qui refuse ou expire, ou des données que la tâche n’attend pas.
3. Un déluge d’actions : une extension qui planifie une action par produit, commande ou client, ou qui replanifie sans cesse la même action.
4. Des lots trop lents : chaque action prend des secondes (appels externes), donc un lot n’en traite que quelques-unes avant sa limite de temps.
5. Des réservations périmées : un runner est mort en plein lot et ses actions restent réservées jusqu’à leur libération.

Diagnostic

1. Lisez la file

Dans Outils → Actions planifiées, regardez les totaux par statut, puis filtrez sur En attente et triez par date : de quand date l’action en retard la plus ancienne ? Filtrez sur Échouée et ouvrez-en quelques-unes : la colonne de journal affiche l’exception ou le message d’erreur.

2. Trouvez les hooks dominants

Sur une copie de la base de données, une requête en lecture seule montre quelles tâches remplissent la file :

SELECT hook, status, COUNT(*) AS total
FROM wp_actionscheduler_actions
GROUP BY hook, status
ORDER BY total DESC
LIMIT 20;

(Remplacez wp_ par le préfixe de vos tables.) Un ou deux hooks représentent généralement la plupart des lignes, et leurs noms désignent l’extension responsable.

3. Vérifiez que le runner s’exécute

• DISABLE_WP_CRON est-il défini dans wp-config.php ? Si oui, une vraie tâche cron appelle-t-elle WP-Cron ou WP-CLI chaque minute ?
• Outils → Santé du site signale-t-il des problèmes d’événements planifiés ou de requêtes loopback ?
• Lancer la file à la main traite-t-il les actions ?

$ wp action-scheduler run --batch-size=50

Journaux et vérifications techniques

• Écran des Actions planifiées : totaux, plus ancienne action en retard, actions échouées et leurs journaux.
• WooCommerce → État → Journaux (fatal-errors) et le journal d’erreurs PHP aux heures où les actions échouent.
• DISABLE_WP_CRON dans wp-config.php ; la crontab du serveur.
• Santé du site pour les problèmes de loopback et d’événements planifiés.
• Taille des tables actionscheduler_actions et actionscheduler_logs.

Solutions

• Lancez WP-Cron depuis le serveur sur les sites à fort ou à faible trafic : définissez DISABLE_WP_CRON et ajoutez une tâche cron qui s’exécute chaque minute.

# crontab : exécute chaque minute les événements cron WordPress échus
* * * * * cd /path/to/wordpress && wp cron event run --due-now --quiet

• Corrigez les tâches en échec : les journaux des actions nomment l’erreur ; corrigez le code ou l’intégration appelée, puis laissez le travail échoué être relancé ou replanifié comme prévu par l’extension.
• Résorbez les accumulations de façon maîtrisée : lancez la file avec WP-CLI aux heures creuses, en surveillant la charge du serveur.
• Arrêtez le déluge à la source : corrigez ou reconfigurez l’extension qui planifie trop d’actions.
• Laissez le nettoyage fonctionner : les actions terminées sont supprimées après la période de rétention dès que le runner fonctionne normalement.
• Ajustez avec prudence : la taille des lots, la limite de temps et les lots simultanés peuvent être augmentés par des filtres, mais seulement une fois le runner fiable et si le serveur en a la capacité.

Ce qu’il ne faut pas faire

• Ne faites pas de TRUNCATE ni de suppressions massives dans les tables d’Action Scheduler. Les lignes en attente incluent des renouvellements d’abonnements, des webhooks, des e-mails et des synchronisations qui n’ont pas encore eu lieu.
• Ne marquez pas des actions échouées comme terminées sans comprendre ce qu’elles devaient faire.
• N’augmentez pas la concurrence sur un serveur déjà en difficulté ; cela ajoute de la charge sans corriger la cause.

Quand faire appel à un expert

Faites appel à un ingénieur quand des actions échouées touchent des paiements, des renouvellements ou des synchronisations de commandes, quand les tables sont énormes et que le site ralentit, ou quand vous ne savez pas quelles actions en attente peuvent être supprimées sans risque.

Problèmes liés

• WooCommerce / Intégrations Webhooks WooCommerce en échec : comment les diagnostiquer Journaux de livraison, codes de réponse, signatures, et pourquoi WooCommerce désactive un webhook après plusieurs livraisons échouées d’affilée. →
• WooCommerce / Performance Checkout WooCommerce lent : quoi vérifier Séparez le temps PHP, les requêtes en base de données et les appels d’API externes avant de changer de cache ou d’hébergement. →
• WooCommerce / Paiements WooCommerce : paiement échoué mais client débité Quand la passerelle encaisse le paiement mais que la commande reste en attente ou échouée, vérifiez le relais des callbacks et des webhooks avant de toucher à la commande. →

Questions fréquentes