Refresco: un estado, una cola y un solo intento

El refresco de credenciales es el lugar donde la autenticación pasa de ser un flujo de pantallas a ser un problema de concurrencia. Mientras el usuario trabaja, la credencial caduca en silencio y hay que renovarla sin interrumpirle; mientras se renueva, otras peticiones siguen saliendo, y cada una de ellas puede descubrir por su cuenta que la credencial ya no vale. La implementación habitual encomienda ese asunto a un interceptor que, ante un rechazo, llama al refresco y reintenta, y esa implementación falla exactamente cuando más importa: cuando cinco peticiones fallan a la vez. Lo interesante es que la solución no requiere ningún mecanismo nuevo de sincronización. Requiere reconocer que renovar es un estado y que un sistema no puede estar dos veces en el mismo estado.

Dos disparadores para un mismo estado

Una renovación puede empezar por dos caminos y conviene no confundirlos, porque tienen origen, fiabilidad y frecuencia distintos. El disparador preventivo es un temporizador que dispara poco antes de la caducidad declarada por el servidor, y su virtud es que la renovación ocurre mientras no hay nada urgente en vuelo. El disparador reactivo es una respuesta rechazada, y su virtud es que no depende del reloj local, que como vimos miente cada vez que el equipo se suspende. Un sistema robusto usa los dos: el preventivo evita la mayoría de los rechazos y el reactivo cubre todos los casos en que el preventivo llegó tarde.

autenticado: {
  after: { ANTES_DE_CADUCAR: 'refrescando' },
  on: {
    RENOVAR: 'refrescando',
    SALIR: 'anonimo',
  },
},
refrescando: {
  // No se declara RENOVAR: volver a entrar aqui es inexpresable.
  invoke: {
    src: 'renovar',
    onDone: { target: 'autenticado', actions: 'guardarSesion' },
    onError: [
      { target: 'expirado', guard: 'esRechazoDefinitivo' },
      { target: 'esperandoReintento' },
    ],
  },
  on: { SALIR: 'anonimo' },
},
esperandoReintento: {
  after: { ESPERA_REFRESCO: 'refrescando' },
  on: { SALIR: 'anonimo' },
},

Ahí está la propiedad central de toda la lección, y cabe en una ausencia: refrescando no declara RENOVAR. Si diez peticiones reciben un rechazo en el mismo milisegundo y las diez envían el evento, la primera provoca la transición y las nueve restantes llegan a un estado que no las escucha, así que el intérprete las descarta sin ruido. No hay bandera que consultar, no hay promesa compartida que memorizar, no hay ventana entre comprobar y actuar donde otro hilo pueda colarse. La exclusión mutua no se implementa: se deduce de que un autómata ocupa un estado a la vez.

Esa diferencia con el interceptor clásico no es de estilo. El interceptor tiene que sostener una variable con la promesa de refresco en curso, comprobarla antes de lanzar la suya, asignarla sin condiciones de carrera y limpiarla en todos los caminos de salida, incluidos los de error; son cuatro oportunidades de equivocarse en un código que nadie mira hasta que un lunes por la mañana media plantilla aparece desconectada. El grafo elimina las cuatro porque no hay variable: el hecho de estar renovando es la posición del sistema, y esa posición es única por definición.

La cola de los que esperan

Garantizar un solo refresco resuelve la mitad del problema. La otra mitad es qué hacen las peticiones que llegan mientras la renovación está en curso, y tiene tres respuestas posibles de las cuales dos son malas. Fallar es inaceptable, porque el usuario vería errores durante una operación que estaba destinada a ser invisible. Salir con la credencial vieja es peor, porque acabará en otro rechazo y multiplicará el ruido. La respuesta correcta es esperar, y esperar bien significa suspender la petición hasta que el estado vuelva a ser estable, sin bloquear nada más.

import { waitFor } from 'xstate'

const renovando = (s: any) => s.matches('refrescando') || s.matches('esperandoReintento')

async function credencialEstable() {
  if (renovando(actorAuth.getSnapshot())) {
    await waitFor(actorAuth, (s) => !renovando(s), { timeout: 15_000 })
  }
  return actorAuth.getSnapshot()
}

export async function peticion(url: string, init: RequestInit = {}, reintentada = false) {
  const previo = await credencialEstable()
  if (!previo.matches('autenticado')) throw new Error('sin sesion')

  const res = await fetch(url, { ...init, credentials: 'include' })
  if (res.status !== 401 || reintentada) return res

  actorAuth.send({ type: 'RENOVAR' })
  const posterior = await waitFor(actorAuth, (s) => !renovando(s), { timeout: 15_000 })
  if (!posterior.matches('autenticado')) throw new Error('sesion terminada')
  return peticion(url, init, true)
}

La función se lee como una conversación con la máquina y esa es justamente la idea: quien hace peticiones no sabe nada de credenciales ni de temporizadores, solo pregunta si el sistema está estable y espera si no lo está. El parámetro reintentada es el guardián contra la recursión infinita, y merece atención porque su ausencia produce el fallo más desagradable del área: una petición que el servidor rechaza por permisos, no por caducidad, dispara un refresco que tiene éxito, se reintenta, se rechaza otra vez, y el bucle solo termina cuando el servidor corta por exceso de llamadas.

sequenceDiagram
participant P as peticiones
participant M as maquina de auth
participant S as servidor
P->>S: tres peticiones con credencial caducada
S-->>P: tres rechazos por credencial
P->>M: RENOVAR por triplicado
M->>M: la primera transiciona, las otras se descartan
M->>S: un unico refresco
S-->>M: credencial nueva
M-->>P: estado autenticado de nuevo
P->>S: tres reintentos, uno por peticion

Varias pestañas, un solo dueño

El grafo garantiza un refresco por actor, y cada pestaña tiene el suyo. Con rotación estricta, dos pestañas que despiertan a la vez reproducen el problema anterior a escala de navegador, y ninguna cantidad de disciplina dentro de la máquina lo evita, porque el conflicto ocurre entre máquinas. La solución conserva el mismo principio, subiéndolo un nivel: que solo una pestaña tenga derecho a renovar y que las demás se enteren del resultado.

const canal = new BroadcastChannel('auth')

canal.onmessage = (e) => {
  if (e.data.tipo === 'sesion') actorAuth.send({ type: 'SESION_EXTERNA', sesion: e.data.sesion })
  if (e.data.tipo === 'fin') actorAuth.send({ type: 'SALIR' })
}

// Solo el titular del cerrojo entra en el estado de refresco.
async function renovarConExclusion() {
  return navigator.locks.request('auth-refresco', async () => {
    const sesion = await renovar()
    canal.postMessage({ tipo: 'sesion', sesion })
    return sesion
  })
}

Lo importante del fragmento no es la interfaz de cerrojos del navegador sino la forma de integrarla: el cerrojo vive dentro del actor invocado, no alrededor de la máquina. La máquina sigue teniendo su estado refrescando y sigue siendo la única fuente de verdad de la pestaña; lo que el cerrojo aporta es que el efecto real se ejecute una vez por navegador en lugar de una vez por pestaña. Y el mensaje de vuelta entra como un evento más, SESION_EXTERNA, que las pestañas seguidoras procesan sin haber renovado nada.