Diseñar automatizaciones que fallen bien

Cuenta con la interrupción

Una automatización es la promesa de que un pequeño trabajo se hará sin que nadie esté mirando. La pregunta de diseño interesante es qué pasa cuando esa promesa no se puede cumplir.

Un resumen programado es un buen ejemplo. Puede leer una colección de notas, agruparlas y guardar un borrador. Cada frontera puede fallar por separado. Tratar todo el flujo como una única acción opaca hace que recuperarse sea más difícil de lo necesario.

Haz que los pasos se puedan repetir

Dale a cada ejecución una identidad estable. Derívala del trabajo que se realiza, como la semana que se resume, y no del momento en que ocurre un reintento. Un reintento debería completar el mismo trabajo sin crear un segundo resultado.

Registra que se ha completado en el punto en que se guarda el resultado. En una implementación real, la comprobación y la escritura deben compartir una transacción o usar una restricción única en la base de datos. Este boceto muestra la idea, no una implementación de almacenamiento completa.

                  type Run = { key: string; notes: Note[] };

async function createBrief(run: Run) {
  const draft = summarize(run.notes);
  // Inserta de forma atómica o devuelve el borrador existente.
  return store.insertOnce(run.key, draft);
}
                

Reintenta con intención

Un fallo temporal de conexión y un permiso que falta necesitan respuestas distintas. Reintenta los fallos temporales con una espera acotada. Detente ante una entrada no válida o un acceso que falta, y haz visible el motivo.

Guarda la etapa actual, la última frontera completada con éxito y la identidad de la entrada. Estos detalles suelen ser más útiles que un mensaje genérico de «algo ha ido mal».

Deja un camino de vuelta

Prefiere crear un borrador antes que enviar, y previsualizar antes que publicar, cuando una decisión humana forma parte del flujo. Un resultado recuperable le da a quien usa la automatización la oportunidad de revisar lo que ha pasado.

La fiabilidad empieza con garantías modestas que puedas explicar. El sistema no necesita ocultar su incertidumbre; necesita que su estado sea comprensible.