Notas privadas repetidas suelen indicar que WooCommerce o una integración reintenta un trabajo sin alcanzar un resultado confirmado. El pedido puede parecer terminado mientras siguen fallando emails, stock, webhooks o fulfilment.
No pulses «ejecutar» en cada acción fallida. Averigua antes si el sistema externo completó el trabajo aunque la llamada local terminase en timeout.
Convierte las notas en una cronología
Lee las notas en orden y agrupa mensajes iguales. Registra primer fallo, intervalo de reintento, resultado reciente y cambios de estado.
- ID de pedido
- ID de acción y hook
- referencia externa
- número de intento
- clase HTTP o error
- efectos ya observadosOculta datos del cliente, credenciales y payloads completos. Una línea temporal breve es más útil que copiar todo el log.
Encuentra la acción programada
Abre WooCommerce > Estado > Acciones programadas y busca por hook, pedido o argumento relacionado. Revisa estado, hora prevista y mensaje.
Acciones Pending muy antiguas apuntan al runner o cron. Fallos con reintentos regulares suelen indicar un problema de aplicación o proveedor. Conserva al menos un registro antes de limpiar: contiene la ruta y la hora necesarias para correlacionar.
Decide si repetir es seguro
Clasifica la operación. Duplicar un aviso interno puede ser molesto; repetir un cobro, crear otro envío o descontar stock tiene consecuencias económicas.
Un timeout solo significa que el emisor no recibió confirmación. Consulta al proveedor por una referencia estable antes de reintentar. Las APIs idempotentes y los IDs de evento deben devolver el mismo resultado ante llamadas repetidas.
Si el código propio no conserva esa referencia, corrígelo antes de reproducir la tarea.
Revisa WP-Cron y capacidad
Confirma que WP-Cron funciona o está sustituido por cron real. Revisa loopback, workers PHP, memoria y salud MySQL.
Mide:
- antigüedad de la acción pendiente más vieja
- crecimiento de la cola
- acciones completadas por minuto
- fatals, locks y timeouts repetidosAumentar procesos puede saturar MySQL si el problema real es una API lenta o una tabla bloqueada. Mide antes de cambiar concurrencia y compara horas normales con picos de pedidos.
Correlaciona PHP y proveedor
Relaciona la ejecución con logs PHP y panel externo. Un 401 suele indicar autenticación; 429, límite; 500, fallo del servicio; un timeout deja resultado desconocido.
No registres tokens ni cuerpos con direcciones. Conserva código de respuesta, ID de petición e ID de pedido. Si DNS o certificados afectan a todas las acciones hacia un proveedor, repara conectividad, no pedidos individuales.
Audita el callback
El código debe validar argumentos, manejar pedidos inexistentes y registrar el resultado durable:
$order = wc_get_order( $order_id );
if ( ! $order ) {
throw new RuntimeException( 'Pedido no disponible para la tarea' );
}En producción también debe proteger datos e implementar idempotencia. No marques una acción Completed antes de que exista el resultado requerido.
Reconcilia y reproduce con límites
Lista pedidos afectados y confirma pago, inventario, email y preparación. Corrige la causa y ejecuta primero una acción de bajo riesgo ya verificada.
Observa notas y resultado externo antes de procesar un lote pequeño. Detén la operación ante cualquier duplicado. No borres el historial completo para mostrar un panel limpio.
Verifica la salud de la cola
Comprueba que nuevas tareas comiencen cerca de su hora, terminen una vez y dejen notas concisas. Prueba un fallo seguro en sandbox.
El mantenimiento recurrente debe alertar por antigüedad, tasa de fallo y crecimiento de cola. Las notas muestran síntomas por cliente; las métricas revelan el problema global antes de que afecte operaciones.