WooCommerce Action Scheduler: coda bloccata

In breve: una coda WooCommerce Action Scheduler è bloccata quando le azioni pending aumentano e la data pianificata è già trascorsa. La diagnosi deve distinguere scheduler non avviato, processo interrotto, azione lenta o callback che fallisce: credenziali e firma di un webhook non sono cause generiche della coda.

Indice dei contenuti

• Confermare che la coda sia realmente bloccata
• Leggere stato e log dell’azione
• Controlli passo per passo
• Correzioni per causa
• Verifica finale
• Domande frequenti
• Fonti tecniche

Confermare che la coda sia realmente bloccata

Apri WooCommerce → Stato → Azioni pianificate e filtra per Pending, Failed e In-progress. Una coda con molte azioni future non è necessariamente anomala; confronta la data pianificata con l’ora del server e osserva se il numero diminuisce durante alcuni minuti.

Leggere stato e log dell’azione

• Pending: l’azione attende un runner o non è ancora scaduta.
• In-progress: un processo l’ha acquisita; se resta così a lungo, controlla timeout o processo interrotto.
• Failed: apri il log della singola azione e individua eccezione, callback e tentativi.
• Complete: verifica che l’effetto atteso sia realmente avvenuto; il completamento dello scheduler non garantisce la riuscita di un servizio remoto.

Non confondere due livelli: Action Scheduler decide quando eseguire una callback; la callback può poi inviare email, aggiornare un ordine o chiamare un webhook. Se la coda avanza ma il servizio remoto fallisce, lo scheduler non è bloccato: va diagnosticato l’esito della singola integrazione.

Controlli passo per passo

1. Controlla WP-Cron. Verifica che DISABLE_WP_CRON e l’eventuale cron di sistema siano coerenti.
2. Esegui un lotto controllato. Da WP-CLI usa gli strumenti Action Scheduler disponibili sul sito e registra durata e uscita; non lanciare migliaia di azioni senza limite.
3. Apri la prima azione fallita. Il primo errore utile è più informativo dei fallimenti successivi in cascata.
4. Controlla PHP e risorse. Cerca fatal error, memory limit, timeout e terminazioni del processo nello stesso intervallo.
5. Individua il gruppo o hook. Se il blocco riguarda un solo plugin, aggiorna o isola quel componente in staging.
6. Verifica le tabelle. Errori SQL, tabelle mancanti o indici danneggiati richiedono backup prima di qualsiasi riparazione.

Correzioni per causa

• Ripristina l’esecuzione regolare di WP-Cron o del cron di sistema.
• Aggiorna WooCommerce e il plugin che registra la callback fallita.
• Correggi il fatal error o riduci il lavoro eseguito dalla singola azione.
• Elimina o annulla azioni soltanto quando ne conosci funzione e conseguenze; ordini, email e rinnovi non vanno cancellati in massa.
• Su code molto grandi usa l’elaborazione a lotti e monitora memoria, tempo e numero di azioni residue.

Code molto grandi

Prima di forzare l’esecuzione, conta le azioni scadute per hook e gruppo. Parti da un lotto ridotto, misura la velocità di smaltimento e interrompi se crescono errori PHP o utilizzo risorse. Una coda che riceve nuove azioni più velocemente di quanto le elabori richiede di correggere il produttore o aumentare la capacità in modo misurato, non un’unica esecuzione senza limiti.

Verifica finale

Per almeno due cicli consecutivi, il numero delle azioni scadute deve diminuire, non devono comparire nuovi fatal error e una nuova azione di prova deve passare da Pending a Complete. Se la callback contatta un servizio esterno, controlla separatamente anche il suo esito.

Domande frequenti

Fonti tecniche

• Action Scheduler — Administration screen
• Action Scheduler — WP-CLI
• Action Scheduler — Per-action data and logs