Reintentos del webhook

LX CloudPos reintenta de forma agresiva los envíos fallidos, con el fin de evitar la pérdida de eventos relevantes. Existen dos capas: reintentos in-process (en memoria, inmediatos) y reintentos persistentes (cron, distanciados en el tiempo).

In-process (síncronos)

Justo después del envío original, LX CloudPos hace hasta 3 intentos con backoff lineal:

Persistentes (cron)

Si los 3 intentos in-process fallan, el envío queda en cola persistente, con el último estado de Hacienda guardado para poder reenviar el mismo payload. Un cron cada 10 minutos drena esa cola, hasta llegar a 5 intentos totales (3 in-process + 2 por cron).

Esto implica que, si el receptor permaneció fuera de servicio durante algunos minutos, el evento se entrega igualmente con posterioridad: no es necesario que el receptor esté en línea en el instante exacto en que Hacienda resuelve el comprobante.

Cuándo se reintenta

Cuándo se detiene el reintento

• Tras los 5 intentos totales (3 in-process + 2 por cron).
• Si se recibe un 4xx distinto de 429 en cualquier intento (error definitivo).
• Si el webhookUrl falla la validación SSRF (URL prohibida).

Cada envío incluye el campo intento en el payload y un nonce único por intento. La lógica de deduplicación debe tolerar la re-entrega del mismo evento.