Antes de repetir una operación fallida, comprueba si llegó a ejecutarse. Perder la confirmación y no haber realizado el cambio son situaciones distintas; tratarlas igual puede duplicar registros o mensajes.
Un error no siempre explica qué ocurrió
Una herramienta puede terminar una acción y perderse la respuesta por un corte de conexión. Si el sistema repite todo sin comprobar el destino, podría crear otra copia. El diagnóstico necesita distinguir fallo previo a la acción, fallo confirmado y resultado desconocido.
Conserva el identificador del trabajo y la información que permita consultar su resultado. Si no se puede comprobar, la salida prudente puede ser dejarlo pendiente para una revisión, en lugar de adivinar que no pasó nada.
Identifica la unidad que se puede repetir
Un proceso puede incluir consulta, borrador y escritura. Repetir una lectura suele tener consecuencias distintas de repetir una escritura. Diseña la recuperación por operación y conserva los pasos ya completados.
Cuando el destino lo permite, utiliza claves o referencias que identifiquen la misma solicitud y comprueba si el cambio existe. La protección concreta depende de la interfaz; no basta con llamar «seguro» al reintento.
Pon límites y un responsable
Define cuántos intentos se harán, con qué espera y cuándo se detendrá el recorrido. Repetir inmediatamente una petición limitada por el proveedor puede mantener el problema y aumentar consumo.
El estado debe explicar qué falta y quién continúa. En nuestra operación de agentes, la identidad del paquete y el recibo ayudan a revisar un relevo antes de prepararlo otra vez.
Prueba el caso incómodo
Incluye una respuesta perdida después de una escritura, una entrada duplicada y un destino temporalmente inaccesible. Comprueba tanto la recuperación como la ausencia de un segundo efecto.
Estas pruebas forman parte de una automatización mantenible. Para la capa de herramientas, la documentación de Make sobre gestión de errores ofrece mecanismos; el diseño debe decidir cuáles corresponden a cada acción.