Time travel debugging: la misma técnica al servicio del desarrollador

Todo lo construido en este nivel tenía un destinatario claro: la persona que usa la aplicación y quiere retroceder. Esta última lección cambia el destinatario sin cambiar la maquinaria. Si el estado se produce aplicando una función pura sobre una secuencia de acciones registradas, entonces cualquier instante pasado de esa ejecución es reconstruible a voluntad, y quien más partido puede sacarle no es el usuario sino quien depura. La demostración que popularizó la idea dura quince segundos y es engañosamente mágica: alguien arrastra un deslizador y la interfaz retrocede sola. Conviene desmontar la magia cuanto antes, porque de ella depende saber cuándo se puede confiar en la herramienta. No hay viaje: hay recálculo. Nada retrocede, nada se deshace, no se restaura ningún estado guardado; simplemente se vuelve a plegar la misma función de transición sobre el estado inicial tomando un prefijo más corto de la lista de acciones, y la interfaz obedece porque es una función del estado y no tiene memoria propia. Entender esa frase es entender a la vez por qué la técnica es tan poderosa, por qué exige una arquitectura muy concreta para funcionar, y por qué hay una clase entera de cosas que no puede devolver jamás.

Dos operaciones que se confunden

Deshacer y viajar en el tiempo se parecen en la pantalla y no se parecen en nada por dentro. Deshacer es una operación del producto: es selectiva, porque retira solo los cambios propios del usuario y respeta los ajenos; es semántica, porque un paso corresponde a una acción percibida y no a un cambio técnico; y es local, porque afecta a un documento y deja fuera la sesión, la configuración y la caché. Viajar en el tiempo es una operación de la herramienta: es global, porque mueve el estado entero de la aplicación a la vez; es mecánica, porque no interpreta el significado de nada; y es no destructiva, porque el registro completo sigue ahí y se puede volver adelante.

type Accion = { type: string; payload?: unknown }

// El estado en el instante n es un pliegue sobre el prefijo de longitud n
function estadoEn<S>(inicial: S, reductor: (s: S, a: Accion) => S, log: Accion[], n: number): S {
  return log.slice(0, n).reduce(reductor, inicial)
}

// Saltar al instante 7 no deshace nada: recalcula desde el principio
const enSiete = estadoEn(inicial, reductor, log, 7)

De esa definición se sigue de inmediato la segunda capacidad, menos vistosa y mucho más útil que el deslizador: si el estado es un pliegue sobre una lista, se puede quitar un elemento del medio y volver a plegar. Eso permite desactivar una acción concreta y ver cómo habría quedado el mundo sin ella, que es la forma más directa de contrastar una hipótesis sobre el origen de un fallo. No estás inspeccionando el pasado: estás construyendo pasados alternativos y comparándolos.

flowchart LR
I[estado inicial] --> R[reductor puro]
L[registro de acciones] --> R
R --> N{cuantas acciones aplicas}
N -->|prefijo corto| A[instante pasado]
N -->|prefijo completo| B[instante actual]
N -->|prefijo con una accion desactivada| C[pasado alternativo]
style R fill:#cba6f7,color:#11111b
style C fill:#a6e3a1,color:#11111b

Las tres condiciones de posibilidad

La técnica no funciona en cualquier arquitectura. Exige tres propiedades, y cada una de ellas es también, por sí sola, una buena práctica que conviene sostener aunque nunca se abra una herramienta de depuración temporal.

La tercera es la que se incumple con más frecuencia y la que se arregla con una disciplina única: la indeterminación se calcula en el borde y se transporta dentro de la acción, nunca se genera dentro de la transición. Es exactamente la misma disciplina que la lección dos exigía a los comandos para que rehacer reconstruyera el estado original, y no es casualidad: ambos problemas son el mismo problema visto desde ángulos distintos.

// Mal: la transicion inventa datos, el replay produce otro estado
function reductorMalo(s: Estado, a: Accion): Estado {
  if (a.type === "crear") {
    return { ...s, items: [...s.items, { id: crypto.randomUUID(), creado: Date.now() }] }
  }
  return s
}

// Bien: la accion transporta lo indeterminado, la transicion es un calculo puro
const crear = () => ({ type: "crear", payload: { id: crypto.randomUUID(), creado: Date.now() } })

Hay un detalle de implementación que conviene anticipar porque decide el rendimiento de toda la herramienta. Replegar el registro completo en cada movimiento del deslizador es correcto pero cuadrático, y en una sesión con miles de acciones la interfaz se vuelve inusable. La solución es la misma que apareció al final de la lección dos: guardar instantáneas periódicas del estado como puntos de apoyo y plegar únicamente desde el más cercano hacia atrás. Es la única memoización que hace falta y convierte el coste de un salto en constante amortizado.

// Un punto de apoyo cada k acciones vuelve constante el coste del salto
const K = 25

function estadoEnRapido<S>(
  apoyos: Map<number, S>, reductor: (s: S, a: Accion) => S, log: Accion[], n: number, inicial: S
): S {
  const base = Math.floor(n / K) * K
  const desde = apoyos.get(base) ?? inicial
  return log.slice(base, n).reduce(reductor, desde)
}

Donde el viaje se rompe

Aquí está el límite que ninguna herramienta futura levantará, porque no es una carencia de implementación sino una propiedad del mundo. El pliegue reconstruye el estado, y solo el estado. Todo lo que la aplicación hizo fuera de su propia memoria permanece hecho. La petición se envió y el servidor la procesó; la fila se insertó en la base de datos; el correo llegó a su destinatario; el evento de analítica quedó registrado; la escritura en el almacenamiento local persiste; la notificación se mostró. Retroceder el deslizador no cancela nada de eso, y la interfaz puede quedar mostrando un pasado coherente consigo mismo pero completamente desalineado con el mundo exterior.

A eso se añaden dos límites prácticos. El primero es el coste: guardar cada acción con su instantánea asociada consume memoria en proporción al tamaño del estado por el número de acciones, y en sesiones largas con estados grandes la herramienta se convierte en el cuello de botella que estaba ayudando a diagnosticar. Por eso las implementaciones serias acotan el registro y permiten filtrar acciones de alta frecuencia. El segundo es la fragilidad frente al cambio de código: un registro grabado con una versión del reductor no reproduce nada fiable con otra versión distinta, de modo que los registros exportados envejecen con el despliegue y deben guardarse acompañados de la referencia exacta del código que los generó.

Con esos límites en la mano, el valor real de la técnica se ve mejor. No es el deslizador, que impresiona en una demostración y se usa poco. Es que el registro de acciones es una descripción completa, compacta y legible de lo que un usuario hizo, y capturarlo cuando algo falla convierte el peor tipo de incidencia —la que no se reproduce— en un caso de prueba determinista que se ejecuta en local y se adjunta a una regresión.

// El registro exportado es el informe de error mas util que existe
function exportarSesion(inicial: unknown, log: Accion[], version: string) {
  return JSON.stringify({ version, inicial, log })
}
// Reproducirlo en local: mismo inicial, mismo log, mismo reductor, mismo fallo

Cuando el replay no basta: grabar la ejecución

El pliegue sobre el registro de acciones es la forma barata de viajar en el tiempo, y su precio es la exigencia arquitectónica: solo funciona si tu aplicación ya está organizada como estado más transiciones puras. Existe una familia distinta de herramientas que consigue lo mismo sin pedirte nada a cambio, y conviene conocerla porque resuelve justo los casos donde la anterior se rinde. En lugar de reconstruir el estado recalculándolo, graban la ejecución entera a bajo nivel, incluyendo todas las fuentes de indeterminación —el reloj, el generador aleatorio, las respuestas de red, el orden de los eventos— y después la reproducen inyectando exactamente los mismos valores. El depurador de reproducción de Mozilla y las herramientas comerciales de grabación de sesiones del navegador funcionan así.

La comparación deja clara la naturaleza del intercambio. El recálculo te da un artefacto que además de reproducir el fallo lo explica, porque una lista de acciones con nombre es legible por un humano y revela la secuencia de intenciones que llevó al problema; la grabación te da fidelidad total sobre una ejecución concreta, pero lo que obtienes es una película, no un guion. En un equipo que controla su arquitectura, el recálculo es casi siempre la mejor inversión, porque el esfuerzo que exige —empujar los efectos a los bordes, mantener el estado serializable— es un esfuerzo que paga dividendos en otras cinco cosas. La grabación es la herramienta correcta cuando el código no es tuyo, cuando el fallo vive en una integración con terceros o cuando reproducir depende de una condición de carrera que ningún registro de acciones captura.