Elección de líder: el bloqueo que nunca se suelta

Con la garantía de liberación en la mano, la elección de líder deja de ser un algoritmo y pasa a ser un truco de tres líneas. No hay votaciones, no hay quórum, no hay mayorías ni identificadores que comparar: hay un nombre, una cola y un navegador que sabe quién está vivo. Lo interesante de este patrón no es su implementación, que verás entera en un minuto, sino todo lo que se sigue de ella —cómo se anuncia un líder, cómo lo descubre quien llega tarde, cómo abdica cuando conviene y qué significa exactamente ser el líder cuando nadie te ha dado un certificado.

El bloqueo que nunca se suelta

Recuerda la regla de la lección anterior: el bloqueo dura lo que tarde en asentarse la promesa que devuelve tu función. Si esa promesa no se asienta nunca, el bloqueo no se suelta nunca. Eso, que en cualquier otro contexto sería un error de programación, aquí es exactamente la declaración que buscas: yo soy el líder hasta que me muera.

// Todas las pestanas ejecutan esto al arrancar. Sin excepciones.
function competirPorElLiderazgo(alSerLider, nombre = 'app-lider-v1') {
  let abdicar;
  const abdicacion = new Promise((resolver) => { abdicar = resolver; });

  const terminado = navigator.locks.request(nombre, { mode: 'exclusive' }, async () => {
    const desmontar = await alSerLider();  // arrancar todo lo que solo hace el lider
    await abdicacion;                      // aqui se retiene el bloqueo
    await desmontar();                     // salida ordenada si abdicamos
  });

  return { abdicar, terminado };
}

Fíjate en lo que no hay en ese código. No hay una rama para el caso de ser seguidor, porque el seguidor no ejecuta nada: su llamada simplemente no ha vuelto todavía. No hay temporizador que compruebe si el líder sigue ahí. No hay identificador de pestaña que comparar para desempatar. Y sobre todo, no hay ninguna lógica de detección de fallos, que es justo la parte que en cualquier otro sistema ocupa el noventa por ciento del código y produce el noventa por ciento de los errores.

La consecuencia es que todas las pestañas ejecutan literalmente la misma línea. La primera que llega entra y se queda; las que llegan después quedan suspendidas en un await que puede durar horas y que no consume nada. Un seguidor no es una pestaña que sepa que es seguidor: es una pestaña cuyo turno todavía no ha llegado.

La cola es la línea de sucesión

El segundo regalo de la API es que la sucesión ya está escrita. Cuando la pestaña líder desaparece, el navegador libera el bloqueo y se lo concede a la siguiente petición de la cola, que estaba esperando desde el principio. Esa pestaña se despierta dentro de su propio callback, ejecuta el arranque del líder y ocupa el puesto. Nadie ha detectado nada, nadie ha votado y no ha hecho falta ningún acuerdo.

flowchart TB
P[Todas las pestanas piden el nombre app-lider en modo exclusivo] --> A[Una lo obtiene y pasa a ser el lider]
P --> B[Las demas quedan en cola sin ejecutar nada]
A --> W[Arranca el worker y abre el almacenamiento]
A --> R[Retiene el bloqueo con una promesa que no resuelve]
R --> M[La pestana lider muere o abdica]
M --> N[El navegador concede el bloqueo al primero de la cola]
N --> A
style A fill:#a6e3a1,color:#11111b
style M fill:#f38ba8,color:#11111b
style N fill:#89b4fa,color:#11111b

El orden de esa cola es el de llegada y se respeta por nombre, así que el relevo es determinista y no una carrera. Eso importa más de lo que parece cuando el navegador restaura una sesión con cuatro pestañas de tu aplicación a la vez: las cuatro piden, una entra y las otras tres quedan ordenadas, de modo que la sucesión ya está decidida antes de que ocurra nada.

Vale la pena comparar esto con lo que habría que escribir sin la API, porque solo así se aprecia lo que se ahorra. Un sistema de latidos necesita que el líder emita una señal periódica, que cada seguidor mantenga un reloj de vencimiento, que alguien decida cuánto silencio equivale a muerte, que la elección subsiguiente tenga desempate para cuando dos seguidores reaccionen a la vez, y que exista un procedimiento para el caso en que el supuesto muerto reaparezca. Son cinco piezas, cada una con sus parámetros y todas ellas fuente de errores intermitentes imposibles de reproducir. Aquí no hay ninguna: la muerte no se estima, se observa, y la observa quien tiene autoridad para hacerlo.

Hay dos matices que conviene tener presentes desde ya, aunque la última lección del nivel los desarrolla. El primero es que el relevo puede tardar: el navegador libera cuando destruye el contexto, y una pestaña suspendida no está destruida. El segundo es que el nuevo líder hereda el puesto pero no el estado: no sabe qué estaba haciendo el anterior, qué transacción quedó a medias ni qué peticiones se quedaron sin respuesta. La sucesión es automática; la recuperación, no.

Anunciarse y ser descubierto

El líder no le sirve de nada a nadie si los demás no saben cómo hablarle. Aquí entra el segundo componente del patrón, que es un canal de difusión compartido por el origen. El líder se presenta cuando toma el mando y responde a quien pregunte; los seguidores preguntan al arrancar y escuchan los anuncios.

const canal = new BroadcastChannel('app-coordinacion');
const miId = crypto.randomUUID();

competirPorElLiderazgo(async () => {
  const epoca = Date.now();              // marca de este mandato
  canal.postMessage({ tipo: 'lider', id: miId, epoca });

  const alMensaje = (ev) => {
    if (ev.data.tipo === 'quien-manda') {
      canal.postMessage({ tipo: 'lider', id: miId, epoca });
    }
  };
  canal.addEventListener('message', alMensaje);

  return () => canal.removeEventListener('message', alMensaje);
});

// Cualquier pestana que arranque y aun no tenga el mando
canal.postMessage({ tipo: 'quien-manda' });

El anuncio al tomar el mando cubre a las pestañas que ya estaban abiertas; la pregunta al arrancar cubre a las que llegan cuando el líder ya lleva rato ahí. Con esas dos piezas nadie se queda sin saber a quién dirigirse, y ninguna de las dos requiere sondear periódicamente.

Queda una pregunta que casi todo el mundo se hace y que conviene contestar con precisión: cómo averiguo si hay líder sin convertirme en uno. La respuesta corta es que hay dos maneras y solo una es aceptable. navigator.locks.query te devuelve una instantánea del origen y puedes mirar si el nombre aparece entre los tomados, pero esa lectura es una fotografía obsoleta en cuanto la recibes y jamás debe gobernar una decisión. La forma correcta es la de arriba: preguntar por el canal y esperar la respuesta del líder, porque quien contesta lo hace desde dentro de su callback, es decir, desde un sitio donde el liderazgo aún es real.

Abdicar a propósito

El líder puede soltar el bloqueo por voluntad propia: basta con resolver la promesa que lo retiene. La abdicación tiene usos legítimos y también una forma muy fácil de hacerse mal, así que conviene separar los casos.

const { abdicar } = competirPorElLiderazgo(arrancarComoLider);

// Caso legitimo: cerrar la sesion o desmontar la aplicacion incrustada
botonCerrarSesion.addEventListener('click', async () => {
  abdicar();                 // libera el bloqueo y desmonta el trabajo del lider
  await terminado;           // esperar a que la salida ordenada acabe
});

Los casos donde abdicar tiene sentido son pocos y todos comparten un rasgo: el líder sabe que va a dejar de ser útil antes de que el navegador se entere. Cerrar la sesión del usuario, desactivar un componente incrustado, aplicar una actualización de la aplicación que exige reabrir el almacenamiento con otro esquema. En todos ellos la abdicación es una salida ordenada que evita que la sucesión ocurra por la vía traumática.

Y hay un caso que parece razonable y no lo es: abdicar porque la pestaña ha pasado a segundo plano. Es tentador pensar que el líder debería ser siempre la pestaña que el usuario está mirando, pero encadenar el liderazgo a la visibilidad produce un baile continuo de relevos cada vez que alguien alterna entre dos pestañas, y cada relevo implica cerrar el almacenamiento, abrirlo de nuevo y rehacer el estado. El coste de mover el mando es alto; el de que el mando esté en una pestaña de fondo, casi siempre bajo. La lección cuatro del nivel se ocupa de cuándo esa intuición sí acierta y de cómo atenderla sin mover el liderazgo entero.