Depurar esta arquitectura: el estado repartido en tres contextos

Llega el momento en que algo va mal y descubres que la habilidad que has usado durante años para arreglar aplicaciones ya no funciona. No es una impresión: es una consecuencia estructural del patrón que acabas de construir. Depurar consiste en observar el estado y retroceder hasta la causa, y esa operación presupone algo que aquí ha dejado de ser cierto —que exista un punto desde el que se vea todo el estado—. En esta arquitectura el estado está repartido entre el hilo de la interfaz, el Worker que posee la base, el disco que sobrevive a ambos y, si el usuario ha abierto varias pestañas, otros tantos hilos de interfaz con sus propias proyecciones. Ninguna consola del navegador ve ese conjunto. La conclusión de esta última lección del bloque es incómoda pero liberadora: el problema no es de depuración sino de observabilidad, y la vista global que te falta tienes que fabricarla tú, por adelantado y a propósito.

Por qué las herramientas no te ayudan

Las herramientas del navegador están construidas sobre una suposición razonable para casi todo el software web y falsa para el tuyo: que hay un contexto principal y que lo demás son accesorios. De ahí salen las cinco carencias concretas que vas a encontrarte.

La consola está segmentada: cada Worker tiene la suya y hay que seleccionarla explícitamente, así que el registro que buscas puede estar delante de ti y no estar mirándolo. No existe una línea de tiempo unificada que entrelace lo que ocurrió en el hilo principal con lo que ocurrió en el Worker, de modo que la relación causal entre un clic y una consulta hay que reconstruirla a mano. Un punto de interrupción detiene un solo contexto, y detener el hilo principal mientras el Worker sigue trabajando produce un sistema que ya no es el que fallaba. El almacén privado del origen no es inspeccionable de forma cómoda ni uniforme: no hay ningún diálogo del sistema que lo abra y en algunos navegadores solo llegas a él escribiendo código que lo recorra. Y las pestañas son invisibles entre sí: no hay ninguna vista que te muestre las cuatro instancias abiertas de tu aplicación, cuál es la líder y en qué versión va cada una.

Sumadas, esas carencias explican por qué los fallos de esta arquitectura tienen un sabor característico. No se manifiestan como excepciones con su pila de llamadas: se manifiestan como ausencias. Algo que debería haber llegado no llega, algo que debería haberse actualizado no se actualiza, una promesa que debería haberse resuelto sigue esperando. Y una ausencia no deja rastro por sí misma, hay que haber preparado el terreno para que se note.

Hay además una carencia conceptual más profunda que las cinco anteriores y que conviene nombrar. Una pila de llamadas es un registro del pasado causal de la ejecución actual: dice quién llamó a quién hasta llegar aquí. En cuanto una operación cruza una frontera de mensajes, esa cadena se corta, y la pila que ves dentro del Worker empieza en su manejador de mensajes, sin ninguna referencia a la interacción del usuario que la originó tres saltos antes. La información no está oculta ni comprimida: no existe, porque nadie la escribió. Reconstruirla es literalmente el trabajo de la sección siguiente, y es la razón de que la instrumentación aquí no sea un lujo de equipos maduros sino un requisito para poder trabajar.

Instrumentar: identidad, tiempo y un registro común

La instrumentación mínima que hace habitable esta arquitectura tiene tres piezas, y ninguna es opcional.

Un identificador de traza que atraviese todos los saltos. Cada operación iniciada por el usuario recibe un identificador que viaja en todos los mensajes que provoca, atraviesa la frontera, aparece en los registros del Worker, vuelve en la respuesta y se adjunta al aviso de cambio resultante. Con él, reconstruir la historia de una interacción se reduce a filtrar por una cadena. Sin él, es arqueología.

Una identidad estable de pestaña. Un identificador corto generado al arrancar y conservado mientras la pestaña viva permite distinguir en un registro compartido quién dijo qué. Es lo que convierte la frase de que la pestaña no se actualiza en la pregunta útil de cuál de las cuatro.

Un reloj comparable entre contextos. Aquí hay un detalle técnico que estropea silenciosamente muchas mediciones: el reloj monótono de alta resolución cuenta desde el instante en que se creó cada contexto, y un Worker se crea después que su página. Comparar directamente esas marcas entre el hilo principal y el Worker produce diferencias inventadas, a veces negativas. Para obtener instantes comparables hay que sumar a cada marca el origen temporal de su propio contexto.

// Un instante comparable entre contextos distintos
const ahora = () => performance.timeOrigin + performance.now();

function trazar(evento, traza, extra) {
  const linea = { t: ahora(), ctx: CONTEXTO, pestana: ID_PESTANA, traza, evento, ...extra };
  anillo.push(linea);                 // buffer circular local, siempre
  if (DEPURACION) canalTrazas.postMessage(linea);   // vista unificada, opcional
}

Dos decisiones de ese fragmento merecen justificación. El búfer circular guarda siempre los últimos cientos de eventos en memoria y puede volcarse a petición: es la respuesta al hecho de que el fallo casi siempre ocurre antes de que a alguien se le ocurra abrir las herramientas, y un registro que solo existe cuando estás mirando no sirve para nada. Y el canal de trazas separado permite que una pestaña recoja los eventos de todos los contextos y los ordene por instante, fabricando la línea de tiempo unificada que las herramientas no te dan.

sequenceDiagram
participant U as Interfaz pestana A
participant L as Worker lider
participant B as Interfaz pestana B
U->>L: peticion traza a91 crear nota
L->>L: transaccion confirmada version 42
L-->>U: respuesta traza a91
L->>B: aviso version 42 traza a91
L->>U: aviso version 42 traza a91
Note over U,B: la misma traza aparece en cuatro registros distintos

Las trampas más comunes

• La promesa que nunca se rechaza. Es la número uno con diferencia. El Worker muere por presión de memoria y las peticiones en vuelo se quedan pendientes para siempre. No hay excepción, no hay error, no hay nada: la aplicación se queda quieta. Cúbrelo con los manejadores de fallo del Worker que rechazan en bloque, y si no lo has hecho, sospéchalo el primero cada vez que algo se cuelgue sin mensaje.
• La consola equivocada. Tu registro está en el Worker y estás leyendo la del documento. Suena tonto y consume tardes enteras; el prefijo de contexto en cada línea lo elimina de raíz.
• El punto de interrupción que cambia el sistema. Detener el hilo principal no detiene el Worker: los mensajes se siguen encolando y al reanudar llegan todos de golpe, en un orden que jamás se habría dado. Para problemas de sincronización, el registro es superior al depurador porque no perturba lo que observa.
• El desarrollo con recarga en caliente. El recargador puede reemplazar tu módulo sin terminar el Worker anterior, dejando dos Workers vivos que compiten por el mismo bloqueo. Produce fallos que no existen en producción y, peor, oculta otros que sí. Termina el Worker explícitamente al descartar el módulo.
• La pestaña con código viejo. Tras un despliegue conviven pestañas de dos versiones hablando el mismo canal. Sin versión de protocolo acordada, los síntomas son arbitrarios y no se reproducen jamás en local.
• Recargar la líder crea dos líderes por un instante. Al recargar, la pestaña libera el bloqueo, otra lo toma, y la recargada vuelve pidiéndolo. Durante ese solapamiento puede haber dos intentos de abrir el fichero, y el que pierde debe degradar a seguidora en lugar de fallar.
• No haber datos y no haberlos todavía. Si tu proyección representa ambas situaciones con el mismo valor vacío, la interfaz mostrará el mensaje de lista vacía durante el arranque y confundirá al usuario y luego a ti. Son tres estados distintos: sin cargar, cargando y cargado vacío.
• El entorno que no reproduce. Una ventana privada o un perfil distinto tienen otro almacén: ahí tu fallo dependiente de datos nunca aparecerá. Y las propias herramientas abiertas alteran el comportamiento, empezando por desactivar la caché de retroceso, que es justo donde vive uno de tus casos límite.

Reproducir lo que solo pasa una vez

La técnica que más rendimiento da en esta arquitectura no es un depurador mejor: es aprovechar una propiedad que el patrón te ha regalado sin pedirla. Si el Worker es el único escritor, si atiende los mensajes en orden y sin ceder el control, y si todo su estado proviene del fichero más la secuencia de mensajes recibidos, entonces el Worker es una máquina determinista. Y una máquina determinista se puede reproducir.

Basta con registrar la secuencia de mensajes de entrada, con su orden y sus argumentos, para poder repetirla después contra un Worker limpio y una copia del fichero. El fallo intermitente que se daba una vez cada doscientas sesiones pasa a darse todas las veces que quieras, en tu equipo, con puntos de interrupción y sin prisa. Es la diferencia entre investigar y adivinar.

// Grabar la entrada del worker durante una sesion de diagnostico
const cinta = [];
self.addEventListener('message', ({ data }) => {
  if (GRABANDO) cinta.push({ n: cinta.length, data: structuredClone(data) });
});

// Reproducir contra un worker limpio y una copia del fichero
async function reproducir(cinta) {
  for (const paso of cinta) {
    worker.postMessage(paso.data);
    await unaVuelta();            // respetar el orden, un mensaje por turno
  }
}

La técnica tiene un límite honesto que hay que declarar: reproduce el comportamiento del escritor, no el de la interfaz ni el del reparto temporal entre pestañas. Un fallo que depende de que dos pestañas hicieran algo a la vez no se reproduce grabando una sola cinta, sino grabando el orden en que el escritor las atendió, que es precisamente el dato que la cinta contiene. Esa es la razón de grabar en el lado del Worker y no en el de cada cliente: el Worker es el único punto del sistema donde todas las historias concurrentes se han fundido ya en una sola secuencia, y esa secuencia es la verdad de lo que ocurrió.

Hay tres condiciones que rompen el determinismo y que conviene vigilar porque son fáciles de introducir sin darse cuenta: las marcas de tiempo tomadas dentro del Worker, los valores aleatorios generados ahí dentro y cualquier lectura de estado externo que no llegue por el canal. Las tres se resuelven de la misma forma, que además mejora el diseño por otros motivos: inyectar el tiempo y la aleatoriedad como argumentos de la operación en lugar de obtenerlos dentro. Un Worker cuya única entrada son los mensajes es un Worker reproducible, comprobable y razonable.