Notes privades repetides acostumen a indicar que WooCommerce o una integració reintenta una feina sense arribar a un resultat confirmat. La comanda pot semblar completada mentre continuen fallant correus, estoc, webhooks o fulfilment.
No executis totes les accions fallides. Primer esbrina si el sistema extern va completar la feina tot i el timeout local.
Converteix les notes en una cronologia
Llegeix-les en ordre i agrupa els missatges idèntics. Registra primer error, interval de reintents, resultat recent i canvis d’estat.
- ID de comanda
- ID d'acció i hook
- referència externa
- número d'intent
- classe HTTP o error
- efectes ja observatsOculta dades personals, credencials i payloads complets. Una cronologia breu resulta més útil que copiar tot el log.
Troba l’acció programada
Obre WooCommerce > Estat > Accions programades i busca per hook, comanda o argument. Revisa estat, hora prevista i missatge d’error.
Accions Pending molt antigues apunten al runner o cron. Errors amb intervals regulars suggereixen aplicació o proveïdor. Conserva almenys un registre abans de netejar-lo: conté la ruta i l’hora necessàries per correlacionar.
Decideix si repetir és segur
Classifica l’operació. Duplicar un avís intern pot ser molest; repetir un cobrament, crear un altre enviament o descomptar estoc té conseqüències comercials.
Un timeout només significa que l’emissor no va rebre confirmació. Consulta el proveïdor amb una referència estable. Les API idempotents i els ID d’esdeveniment han de retornar el mateix resultat davant peticions repetides.
Si el codi propi no conserva la referència, repara’l abans de reproduir la tasca.
Revisa WP-Cron i la capacitat
Confirma que WP-Cron funciona o està substituït per un cron real. Revisa loopback, workers PHP, memòria i salut de MySQL.
Mesura:
- edat de l'acció pendent més antiga
- creixement de la cua
- accions completades per minut
- fatals, bloquejos i timeoutsAfegir processos pot saturar MySQL si el problema és una API lenta o una taula bloquejada. Mesura abans de canviar concurrència i compara hores normals amb pics de comandes.
Comprova si una acció molt lenta bloqueja les següents o si hi ha grups de cua independents. Reiniciar cron sense retirar el coll d’ampolla només acumula més intents. Estableix un temps màxim coherent amb el proveïdor i deixa l’operació en estat recuperable quan se supera.
Correlaciona PHP i el proveïdor
Relaciona l’execució amb logs PHP i el panell extern. Un 401 sol indicar autenticació; 429, límit; 500, error del servei; un timeout deixa el resultat desconegut.
No registris tokens ni cossos amb adreces. Conserva codi de resposta, ID de petició i comanda. Si DNS o certificat afecta totes les accions cap al mateix proveïdor, repara la connectivitat.
Audita el callback
El codi ha de validar arguments, gestionar una comanda inexistent i registrar un resultat durable:
$order = wc_get_order( $order_id );
if ( ! $order ) {
throw new RuntimeException( 'Comanda no disponible per a la tasca' );
}En producció també ha de protegir dades i implementar idempotència. No marquis Completed abans que existeixi el resultat requerit.
Reconcilia i reprodueix amb límits
Llista les comandes afectades i confirma pagament, inventari, correu i preparació. Corregeix la causa i executa primer una acció de risc baix.
Observa les notes i el resultat extern abans de processar un lot petit. Atura’t davant qualsevol duplicat. No eliminis tot l’historial només per netejar el panell.
Verifica la salut de la cua
Comprova que les tasques noves comencin a prop de l’hora, acabin una vegada i deixin notes concises. Prova un error segur en sandbox.
El manteniment recurrent ha d’alertar per antiguitat, taxa d’error i creixement. Les notes mostren símptomes individuals; les mètriques detecten el problema general abans que afecti les operacions.