Qué comprobar antes de repetir una llamada que pudo crear un pedido

Conserva el rastro del primer envío

Reúne referencia de solicitud, cuenta destino, clave utilizada, parámetros aprobados y momento del envío. Anota qué recibiste realmente: respuesta de error, desconexión o ninguna respuesta dentro del plazo. No cambies esos datos para probar de nuevo. Si la interfaz permite otra pulsación, debe recuperar la misma operación pendiente y explicar su estado, evitando que otra persona cree un pedido mientras investigas.

Consulta por una referencia inequívoca

Busca el identificador externo que mandaste o recupera el resultado mediante el mecanismo documentado por el proveedor. Comprueba que cliente, líneas y versión coinciden. Nombre, importe y fecha solo sirven como pistas: dos compras iguales pueden existir. Si la búsqueda aún puede estar retrasada, su ausencia no acredita que la creación falló. Documenta la consistencia y los filtros del recurso consultado; no inventes una búsqueda por clave si la API no la ofrece.

Aplica una decisión de tres salidas

Si hay pedido confirmado, guarda su referencia y continúa los pasos pendientes. Si existe una protección idempotente vigente y aplicable, repite la misma intención siguiendo su contrato. Si ninguna comprobación resuelve la duda, bloquea la nueva creación y deriva el caso. En Stripe las reglas difieren entre versiones de API; en una aplicación de pedidos debes revisar sus propias garantías. Una nueva clave elimina precisamente la relación que podría proteger el reintento.

Haz que el operador pueda resolver sin duplicar

La bandeja de revisión debe mostrar el envío original, sus referencias, búsquedas realizadas y candidatos encontrados. Ofrece acciones diferentes para enlazar un pedido existente y para autorizar una creación nueva. La primera debe exigir el identificador destino; la segunda, una justificación y una comprobación actualizada. Consultar el pedido no concede permiso para anularlo ni cambiar sus condiciones.

Si otra persona gestionó el caso manualmente durante la incidencia, incorpora esa referencia antes de reanudar. En un ejemplo hipotético, comercial puede haber creado una orden por teléfono mientras la automatización esperaba: el flujo debe reconocer esa resolución. Mantén la operación retenida hasta confirmar qué registro satisface la intención original. Un comentario «revisado» sin referencia al efecto no basta para justificar un nuevo envío ni para cerrar el caso.

Ensaya el fallo después de crear

La prueba relevante interrumpe la respuesta después de que el destino haya guardado el pedido. Comprueba desde otro acceso que existe una sola creación y que el flujo local acaba enlazándola. Añade un caso con búsqueda temporalmente vacía y otro con dos candidatos. El operador debe ver la incertidumbre y poder confirmar el registro correcto con autoridad de negocio. No cierres la incidencia solo porque el segundo envío responde: verifica también el primer efecto y cualquier reserva o comunicación dependiente.

Fuentes y documentación

• Azure Architecture Center: Retry — Distingue fallos transitorios, límites de intentos e impacto de políticas anidadas.
• Stripe: solicitudes idempotentes — El contrato cambia entre API v1 y v2; revisa conservación de claves, parámetros y resultados.