Reintentos y backoff: el intento como estado

El reintento es la operación asíncrona que peor envejece cuando se escribe a mano. Empieza siendo un while con un contador, gana un await de espera, luego un techo para no esperar diez minutos, luego una condición para no reintentar los errores que no lo merecen, y termina siendo veinte líneas dentro de una función que nadie puede observar, cancelar ni probar por partes. Modelar los intentos como estados invierte esa trayectoria: el contador deja de ser una variable escondida y pasa a ser contexto visible, la espera deja de ser un await opaco y pasa a ser una transición temporizada que se cancela sola al salir del estado, y la decisión de rendirse deja de estar enterrada en una condición para ser un estado con nombre al que la UI puede reaccionar.

El intento como estado, no como bucle

La transformación es sencilla de enunciar: donde había una iteración, pon dos estados —uno que ejecuta y otro que espera— y una arista que los une. El contador de intentos vive en el contexto, la guarda decide si queda margen y el agotamiento tiene su propio destino.

import { setup, assign, fromPromise } from 'xstate'

const MAXIMO = 4

export const lectura = setup({
  types: {
    context: {} as { intentos: number; error: unknown },
    events: {} as { type: 'CARGAR' } | { type: 'CANCELAR' } | { type: 'REINTENTAR' },
  },
  actors: {
    leer: fromPromise(async ({ signal }: { signal: AbortSignal }) => {
      const res = await fetch('/api/informe', { signal })
      if (!res.ok) throw Object.assign(new Error('http'), { status: res.status })
      return res.json()
    }),
  },
  guards: {
    quedanIntentos: ({ context }) => context.intentos < MAXIMO,
  },
  delays: {
    ESPERA: ({ context }) => Math.min(20_000, 2 ** context.intentos * 400),
  },
}).createMachine({
  initial: 'inactivo',
  context: { intentos: 0, error: null },
  states: {
    inactivo: { on: { CARGAR: 'cargando' } },
    cargando: {
      entry: assign({ intentos: ({ context }) => context.intentos + 1 }),
      invoke: {
        src: 'leer',
        onDone: { target: 'exito', actions: assign({ intentos: 0 }) },
        onError: [
          { target: 'esperando', guard: 'quedanIntentos', actions: assign({ error: ({ event }) => event.error }) },
          { target: 'agotado', actions: assign({ error: ({ event }) => event.error }) },
        ],
      },
    },
    esperando: {
      after: { ESPERA: 'cargando' },
      on: { CANCELAR: 'inactivo' },
    },
    exito: { on: { CARGAR: 'cargando' } },
    agotado: { on: { REINTENTAR: { target: 'cargando', actions: assign({ intentos: 0 }) } } },
  },
})

Tres propiedades aparecen gratis con esta forma y ninguna existía en el bucle. La primera es la observabilidad: esperando es un estado real, así que la interfaz puede decir reintentando en cuatro segundos en lugar de fingir que sigue cargando. La segunda es la cancelabilidad: el evento CANCELAR sale de esperando y el temporizador se descarta automáticamente, sin banderas ni identificadores de setTimeout que limpiar. La tercera es la distinción entre fallo transitorio y fallo definitivo: agotado no es lo mismo que un error cualquiera, y darle estado propio permite ofrecer ahí el botón de reintento manual que reinicia el contador.

El retardo como transición temporizada

La espera entre intentos merece atención propia porque es donde vive el diseño real. Una espera fija reintenta demasiado pronto cuando el servidor está congestionado y demasiado tarde cuando el fallo fue un parpadeo de red. La curva exponencial resuelve ambos extremos: rápida al principio, prudente después, con un techo que evita esperas absurdas.

delays: {
  ESPERA: ({ context }) => {
    const base = Math.min(20_000, 2 ** context.intentos * 400)
    return Math.round(base / 2 + Math.random() * (base / 2))
  },
}

Esa segunda línea es el jitter, y omitirlo es el error clásico. Sin aleatoriedad, todos los clientes que fallaron a la vez —porque el servidor cayó a la vez para todos— vuelven a llamar exactamente a la vez, y el reintento se convierte en una segunda oleada tan sincronizada como la primera. El jitter dispersa la oleada en el tiempo: cada cliente espera entre la mitad y el total de su ventana, y la avalancha se convierte en una lluvia fina que el servidor sí puede absorber mientras se recupera.

stateDiagram-v2
[*] --> inactivo
inactivo --> cargando: CARGAR
cargando --> exito: resultado
cargando --> esperando: fallo con intentos restantes
cargando --> agotado: fallo sin intentos
esperando --> cargando: vence el retardo
esperando --> inactivo: CANCELAR
agotado --> cargando: reintento manual

Qué se reintenta y qué no

Reintentar todo es tan malo como no reintentar nada: multiplica la carga sin cambiar el desenlace y retrasa el mensaje honesto que el usuario merecía ver de inmediato. La guarda que decide debe mirar la clase del fallo, no solo el contador.

guards: {
  esTransitorio: ({ event }) => {
    const status = (event as any).error?.status
    return status === undefined || status === 429 || status >= 500
  },
}

Con esa guarda encadenada antes de quedanIntentos, el grafo distingue tres desenlaces distintos ante un error: esperar y volver, rendirse tras agotar intentos, o fallar de inmediato porque el error nunca iba a curarse con tiempo. Ese tercer camino es el que casi ninguna implementación casera tiene, y es el que evita que un formulario mal rellenado tarde treinta segundos en decir que un campo era obligatorio.

El reintento que no te pertenece

Antes de escribir todo lo anterior conviene comprobar si alguien ya lo hace. Una cache de estado de servidor trae reintentos con retardo configurable, y si tu petición es una lectura simple, la política de la librería es suficiente y no necesita grafo. La máquina aporta cuando el reintento deja de ser una decisión técnica invisible y pasa a ser parte de la experiencia: cuando el usuario ve la cuenta atrás, cuando puede cancelarla, cuando el agotamiento abre un camino alternativo en el flujo o cuando el número de intentos condiciona pasos posteriores del procedimiento.