Comprueba qué pasa si la misma solicitud llega dos veces.

Ejemplo ficticio: la solicitud S-17 debe crear una única tarea. Usa el identificador de solicitud como referencia para reconocer esa operación. Dos solicitudes diferentes de la misma persona no son necesariamente duplicados.

Acordad qué ocurre si S-17 llega otra vez con una cantidad distinta. Puede ser una corrección o un conflicto; no descartes el cambio solo porque el identificador coincide.

MDN define la idempotencia por conservar el efecto previsto al repetir una petición idéntica, y señala que POST no la garantiza. No asumas que un botón de reintento o un método HTTP resuelve por sí solo la duplicación del proceso.

En este ejemplo, pide que una repetición reconocida permita consultar la tarea ya creada. La implementación debe gestionar también dos entradas simultáneas; una comprobación manual seguida de creación no demuestra ese comportamiento.

Caso uno: envía S-17 dos veces y comprueba que existe una sola tarea. Caso dos: simula que se crea la tarea pero se pierde la respuesta; al reintentar debe poder localizarse el resultado previo.

Caso tres: entrega dos copias al mismo tiempo con ayuda del equipo técnico. Comprueba el número real de tareas, no solo los mensajes de éxito. Registra también qué devuelve el flujo a quien envió la segunda copia.

Guarda la relación entre identificador de entrada y resultado, junto con el estado que necesita quien opera el flujo. Define qué hacer con datos distintos bajo el mismo identificador y cuándo interviene una persona.

Si tu herramienta no permite demostrar la repetición segura, limita los reintentos automáticos y deja un procedimiento de revisión. Añade estos casos a las pruebas cuando cambies el flujo o su destino.