¿Ese envío que agotó el tiempo guardó de verdad tu trabajo?

El botón gira, la pestaña muestra un error y el formulario que tardaste diez minutos en rellenar ha desaparecido. Lo que no sabes es si la escritura llegó antes de que muriera la conexión. Tratar esa incógnita como un fallo es como se crean comentarios duplicados, pedidos dobles y tickets de soporte repetidos.

Recupera en un orden fijo: conserva el texto, encuentra el resultado y solo entonces decide si se permite un segundo envío.

Empieza por el texto y la marca de tiempo

Copia el contenido de la página antes de tocar cualquier otra cosa, incluido cualquier borrador que el navegador todavía mantenga en el campo. Anota la hora, la página en la que estabas y la acción que realizaste, porque esos tres detalles son los que hacen posible el resto de la investigación. Si la pestaña sigue abierta, déjala abierta hasta que hayas leído la entrada de red. Guardar el texto no cuesta nada y perderlo cuesta toda la tarea.

Después separa las dos formas de fallo que realmente puedes observar. Una conexión que cayó a mitad de la petición y un servidor que respondió con un error se ven distintos en el panel de red, y solo la segunda te dice algo sobre la decisión de la aplicación.

Busca el resultado en la vista propia de la aplicación

Recarga la vista de lectura que mostraría el resultado: la lista de comentarios, el historial de pedidos, la cola de tickets o el registro que estabas editando. Compara por cuenta, destino, hora y contenido en lugar de por la entrada más reciente, porque otra persona puede haber escrito después de ti. Para una tarea en segundo plano, busca la referencia existente y su estado en lugar de crear una operación nueva como prueba de conectividad.

Si el resultado está ahí, has terminado y el error pertenece al camino de la respuesta, no a la escritura. Si no está, mantén la posibilidad de que la aplicación aún no lo haya confirmado: una tarea en cola, una vista de lectura retrasada o una réplica rezagada pueden ocultar durante un tiempo una escritura correcta.

Dale un segundo vistazo definido antes de sacar una conclusión y anota la hora de ambas comprobaciones. Dos comprobaciones separadas veinte segundos son mucha menos prueba que dos separadas diez minutos.

Decide si un segundo envío es seguro

La respuesta depende de la operación, no de tu paciencia. HTTP separa los métodos que pueden repetirse con el mismo efecto previsto de los que no, y aconseja no reintentar automáticamente los del segundo tipo salvo que se sepa que la semántica lo permite. Crear un comentario, hacer un pedido y enviar un pago suelen estar en el segundo grupo, por eso un segundo clic que parece correcto no dice nada sobre el primero.

Si mantienes el cliente, usa el mecanismo de reintento o de idempotencia que documenta la API, y átalo a la misma operación lógica en lugar de generar una clave nueva para cada intento. Un identificador de petición usado para el seguimiento no es una clave de supresión de duplicados salvo que el servidor lo trate como tal.

curl -i -X POST https://api.example.net/v1/orders \
  -H "Idempotency-Key: 6f1c2a94-3b7e-4a10-9c22-5d0e8f7b1a63" \
  -H "Content-Type: application/json" \
  --data @order.json

La clave solo ayuda si el servicio la guarda asociada a la operación y devuelve el resultado original en una repetición. Prueba ese comportamiento en un punto de prueba antes de confiar en él en producción.

Recoge pruebas antes de volver a pulsar nada

Conserva la entrada de red en lugar de una captura de pantalla del error. El método de la petición, la URL, la respuesta o el tiempo de espera y la hora en que ocurrió son lo que un administrador puede correlacionar con los registros de la aplicación. Exporta o copia la entrada como un comando solo si después quitas de la copia las cookies, las cabeceras de autorización y cualquier contenido privado. Deja intacta tu propia sesión y no repitas nunca una petición capturada con credenciales como atajo.

Pregunta al propietario del servicio una pregunta concreta: ¿la operación con este contenido en este momento tuvo éxito y hay una referencia? Esa pregunta tiene respuesta, mientras que "se rompió el sitio" no la tiene.

El sentido del ejercicio es establecer que la acción ocurrió exactamente una vez. Un mensaje de error que puedes descartar no es lo mismo que un registro en el que puedes confiar, y el segundo es lo que necesitas antes de enviar cualquier otra cosa.