¿El proceso ha fallado o solo has perdido la respuesta?
Una conexión se corta justo después de que una aplicación reciba una petición. Tu proceso muestra un error, pero eso no demuestra que la operación no se haya hecho. Si vuelves a enviarla sin comprobar nada, puedes acabar con dos fichas, dos reservas o dos avisos. La pregunta útil es qué ha pasado en el sistema de destino.
Un error de respuesta no explica el resultado
Conviene separar tres situaciones: una petición rechazada antes de empezar, una operación confirmada y un resultado desconocido. Este último estado necesita una comprobación, no una repetición automática a ciegas. Guarda el identificador de la petición y busca el resultado en el servicio que debe conservarlo.
En un flujo administrativo, por ejemplo, un fallo al recibir la confirmación no es motivo suficiente para crear otra ficha. Primero mira si la primera ya existe. Es un ejemplo de diseño, no una descripción del comportamiento de cualquier programa.
Una misma operación necesita una misma identidad
Algunas API admiten claves de idempotencia: un identificador que permite reconocer un reintento de la misma operación. Stripe documenta este mecanismo para evitar crear la operación dos veces. El comportamiento concreto depende del servicio, de la versión y de cuánto tiempo conserva la clave.
No generes una clave nueva para cada intento si quieres que el destino los reconozca como la misma operación. Tampoco reutilices una clave para operaciones distintas. Evita incluir datos personales. Si el servicio no ofrece este mecanismo, diseña una comprobación de duplicados y una revisión de resultados inciertos; una búsqueda previa, por sí sola, no elimina todas las coincidencias entre procesos simultáneos.
Prueba el corte, no solo el camino correcto
En un entorno de pruebas, comprueba qué ocurre cuando se pierde la respuesta después de guardar el resultado. Revisa también dos peticiones simultáneas, datos cambiados y un reintento fuera del periodo admitido por el servicio. No hagas estas pruebas con cobros ni comunicaciones reales.
Deja un registro que relacione la operación, los intentos y el resultado final, con el mínimo de datos necesario. Define cuándo se detiene el proceso para resolver el resultado incierto. Un reintento es útil cuando recupera una operación; deja de serlo cuando crea una segunda sin que nadie lo vea.