Cómo probar un reintento de webhook tras un fallo a mitad del proceso

Un webhook informa a tu software de que ocurrió algo en otro sistema. Si el emisor repite la notificación, la aplicación no debería repetir automáticamente la operación del negocio. Una finalización de servicio puede generar varios intentos de entrega, mientras el cliente debería recibir el seguimiento previsto una sola vez y la oficina debería ver una tarea correspondiente.

Este ejercicio se centra en un intervalo difícil: el destino cambia, pero el receptor falla antes de registrar la finalización. Combina esa interrupción con copias simultáneas del mismo evento. La pregunta es si la recuperación puede confirmar un único efecto previsto sin perder ni repetir la operación.

Define qué debe ocurrir una sola vez

Elige un proceso hipotético: una inspección finalizada crea una tarea de revisión. Identifica el emisor, el tipo de evento, el registro de origen, la tarea de destino y cualquier notificación. Escribe el efecto esperado: “Una finalización crea una tarea de revisión para esa inspección”.

Por ejemplo, la documentación de webhooks de Stripe advierte que los eventos pueden entregarse más de una vez y que su orden de llegada no está garantizado. El comportamiento depende del proveedor: revisa las condiciones del emisor concreto en lugar de asumir que todos funcionan igual.

Distingue la entrega repetida de un evento de dos eventos válidos sobre la misma inspección. Una corrección y una finalización pueden pertenecer al mismo registro y necesitar decisiones distintas. Eliminar duplicados solo por número de cliente o de inspección podría bloquear trabajo legítimo.

Acuerda la identidad y los estados de procesamiento

Pregunta al equipo qué identificador estable representa el evento y cómo se delimita por emisor y cuenta. Si el proveedor no ofrece un identificador adecuado, la clave de negocio alternativa necesita una definición explícita y una revisión.

Define estados observables: recibido, pendiente de procesamiento, completado, fallido y pendiente de conciliación. Registrar que llegó una petición no demuestra que se creó su tarea. Del mismo modo, un tiempo de espera agotado no demuestra que la tarea no exista.

El intervalo delicado está entre modificar el destino y registrar el éxito. Pregunta qué ocurre si el proceso se interrumpe ahí. Una operación atómica podría servir si ambos registros comparten base de datos; un proveedor externo puede requerir su propia función de idempotencia o una conciliación. La prueba debe exponer ese intervalo sin imponer una arquitectura que el sistema no pueda admitir.

Realiza un ensayo de repetición controlado

En un entorno de pruebas, crea eventos ficticios y evita enviar mensajes a clientes reales. Registra cuántas tareas existen inicialmente y cuál será la referencia esperada. Ejecuta estos casos:

1. Entrega el evento normalmente y verifica la tarea prevista y el estado de procesamiento.
2. Envía otra vez exactamente el mismo evento. Comprueba el destino y las notificaciones, además de la respuesta HTTP.
3. Envía dos copias simultáneas. Confirma que los procesos concurrentes no puedan crear ambos la tarea.
4. Interrumpe el procesamiento después de actuar sobre el destino y antes de registrar la finalización local. Reintenta y busca un efecto ya existente.
5. Envía otro evento válido para la misma inspección y comprueba que la regla no descarte demasiado.
6. Inspecciona el caso interrumpido antes de otro intento. Comprueba que el operador pueda distinguir una acción incompleta de una tarea ya creada cuya confirmación falta.

El desarrollador debe controlar el punto de interrupción. Desconectar un navegador al azar puede no reproducir nunca el intervalo de fallo del servidor que necesitas examinar.

Verifica la confirmación y la recuperación

Acuerda cuándo confirma el receptor la entrega. Si responde después de poner el trabajo en una cola, esa cola debe conservar información suficiente para completar o investigar la acción. Una respuesta exitosa no debería dejar una tarea sin seguimiento que desaparezca al reiniciar.

Ante un fallo, el operador necesita la referencia de origen, el estado actual, el último intento y una siguiente acción apropiada. Excluye secretos e información personal innecesaria. Distingue “se puede reintentar” de “primero comprueba si el destino ya cambió”.

En el ejemplo de la inspección, un caso incierto debería permitir localizar la tarea correspondiente antes de aprobar otro intento. “Reintentar todo” no debe ser el único mecanismo de recuperación. Define quién puede hacerlo, qué evidencia necesita y dónde queda registrada la decisión.

Conserva evidencia breve y repetible

Guarda identificadores de eventos, horas de los intentos, casos ejecutados, referencias de destino y número observado de notificaciones. Indica si el efecto esperado ocurrió una vez y si siguió siendo posible procesar cambios posteriores legítimos. Una respuesta exitosa del endpoint no contesta esas preguntas por sí sola.

Repite el ensayo cuando cambien el mapeo de eventos, la cola, la creación en destino o las condiciones del proveedor. Son pruebas ilustrativas, no una afirmación de que una integración de Dynelink ya las haya superado.

Contacta con Dynelink para definir pruebas de entregas duplicadas y reglas de recuperación antes de que las notificaciones repetidas se conviertan en trabajo repetido.