Reconexión y degradación: sobrevivir a la red inestable

Un recurso de vida larga tiene un problema que una petición puntual no tiene: cuando se cae, no basta con volver a pedirlo. Había suscripciones activas, había una posición en el medio, había mensajes que se enviaron y quizá no llegaron, había una sesión que el servidor identificaba. Reintentar una petición fallida es repetir una función; reconectar un recurso es restaurar un contexto, y esa diferencia obliga a que el grafo tenga posiciones que el reintento simple no necesitaba. A eso se añade una asimetría todavía menos atendida: entre funcionar y fallar hay un territorio enorme de funcionar peor, y un sistema que solo sabe distinguir los extremos rompe en situaciones donde podría haber seguido sirviendo con menos resolución, menos frecuencia o menos garantías. Modelar la degradación como estados explícitos es lo que separa un cliente frágil de uno que la gente puede usar en un tren.

Reconectar es un estado, y restaurar es otro

El grafo de reconexión tiene tres posiciones que el reintento simple no necesitaba. esperando_reconexion es la pausa entre intentos, y existe para que el usuario vea una cuenta atrás en lugar de un limbo. reconectando es el intento en curso. restaurando es la fase que casi nadie declara: tener el enlace abierto no significa haber recuperado el servicio, porque faltan las suscripciones, la posición y los mensajes pendientes de confirmación.

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

const TECHO = 30_000

export const enlace = setup({
  types: {
    context: {} as { intentos: number; pendientes: unknown[]; motivo: string | null },
    events: {} as
      | { type: 'ABIERTO' } | { type: 'CAIDO'; motivo: string } | { type: 'RESTAURADO' }
      | { type: 'RENDIRSE' } | { type: 'REINTENTAR_YA' },
  },
  actors: { socket: fromCallback(() => () => {}) },
  guards: { quedanIntentos: ({ context }) => context.intentos < 8 },
  delays: {
    ESPERA: ({ context }) => {
      const base = Math.min(TECHO, 2 ** context.intentos * 500)
      return Math.round(base / 2 + Math.random() * (base / 2))
    },
  },
}).createMachine({
  id: 'enlace',
  initial: 'conectando',
  context: { intentos: 0, pendientes: [], motivo: null },
  states: {
    conectando: {
      entry: assign({ intentos: ({ context }) => context.intentos + 1 }),
      invoke: { id: 'socket', src: 'socket' },
      on: {
        ABIERTO: 'restaurando',
        CAIDO: [
          { target: 'esperando_reconexion', guard: 'quedanIntentos' },
          { target: 'desconectado' },
        ],
      },
    },
    restaurando: {
      invoke: { id: 'socket', src: 'socket' },
      on: {
        RESTAURADO: { target: 'conectado', actions: assign({ intentos: 0, motivo: null }) },
        CAIDO: 'esperando_reconexion',
      },
    },
    conectado: {
      invoke: { id: 'socket', src: 'socket' },
      on: { CAIDO: { target: 'esperando_reconexion', actions: assign({ motivo: ({ event }) => event.motivo }) } },
    },
    esperando_reconexion: {
      after: { ESPERA: 'conectando' },
      on: { REINTENTAR_YA: 'conectando', RENDIRSE: 'desconectado' },
    },
    desconectado: {
      on: { REINTENTAR_YA: { target: 'conectando', actions: assign({ intentos: 0 }) } },
    },
  },
})

stateDiagram-v2
[*] --> conectando
conectando --> restaurando: ABIERTO
restaurando --> conectado: RESTAURADO
conectado --> esperando_reconexion: CAIDO
restaurando --> esperando_reconexion: CAIDO
conectando --> esperando_reconexion: fallo con intentos restantes
conectando --> desconectado: fallo sin intentos
esperando_reconexion --> conectando: vence la espera
esperando_reconexion --> desconectado: RENDIRSE
desconectado --> conectando: REINTENTAR_YA

El jitter de la línea del retardo no es un adorno estadístico. Sin él, todos los clientes que perdieron el enlace a la vez —porque el servidor cayó a la vez para todos— vuelven a llamar exactamente a la vez, y la reconexión se convierte en una segunda oleada tan sincronizada como la caída. Dispersar cada espera entre la mitad y el total de su ventana transforma la avalancha en una lluvia fina que el servidor sí puede absorber mientras se levanta.

Degradar antes que romper

La segunda idea es que el fallo rara vez es binario. Entre servir a plena calidad y no servir hay una escalera, y recorrerla hacia abajo mantiene vivo el servicio en condiciones donde la alternativa era un error. La escalera se modela como estados hermanos ordenados, con eventos que bajan un peldaño ante señales de sufrimiento y suben uno ante señales de holgura sostenida.

calidad: {
  initial: 'alta',
  states: {
    alta: { on: { SUFRE: 'media' } },
    media: { on: { SUFRE: 'baja', HOLGURA: 'alta' } },
    baja: { on: { SUFRE: 'solo_audio', HOLGURA: 'media' } },
    solo_audio: { on: { HOLGURA: 'baja' } },
  },
}

Las dos asimetrías de este fragmento son deliberadas y ambas provienen de la experiencia. La primera es que se baja rápido y se sube despacio: la degradación responde a la primera señal de sufrimiento, mientras que la recuperación exige holgura mantenida durante una ventana, porque subir de peldaño al primer respiro produce oscilación visible y molesta. La segunda es que se baja de uno en uno en lugar de saltar al fondo, porque cada peldaño es una hipótesis sobre cuánto ancho de banda hay y conviene comprobarla antes de renunciar del todo.

La red como región que informa sin mandar

La tentación al llegar aquí es hacer que la región de red controle directamente a las demás, y es un error de acoplamiento. La red no debe decidir la calidad ni el transporte: debe publicar hechos que las otras regiones interpretan según sus propias reglas. Así la política de cada dimensión se puede cambiar por separado, y la región de red se puede probar sin montar nada más.

Lo inestable se prueba de forma determinista o no se prueba. La receta consiste en tres piezas: un reloj simulado que permita adelantar el tiempo sin esperarlo de verdad, una fuente de aleatoriedad inyectada para que el jitter sea reproducible fijando la semilla, y un doble del recurso que emita fallos y recuperaciones bajo tu control. Con esas tres piezas puedes afirmar propiedades exactas: que la quinta espera está entre dos valores concretos, que el contador se reinicia solo tras la restauración completa, que salir de la espera cancela el temporizador y nada se dispara después.

const espera = (intentos: number, azar: number) => {
  const base = Math.min(30_000, 2 ** intentos * 500)
  return Math.round(base / 2 + azar * (base / 2))
}
// espera(4, 0) === 4000 y espera(4, 1) === 8000: la ventana es verificable