Por qué depurar async es difícil: la pila miente y la tarea no está ahí

Todo lo que aprendiste sobre depurar descansa en una premisa silenciosa: que la pila de llamadas es la historia del programa. El depurador para el hilo, lees la pila hacia arriba y ves quién llamó a quién; pones un breakpoint y atrapas el flujo en el acto. Async rompe esa premisa de raíz. Cuando escribes .await, el compilador no genera una llamada que se apila: genera una máquina de estados que retorna al executor cada vez que tendría que esperar. La consecuencia es que la pila del hilo ya no refleja tu lógica —refleja el bucle del runtime—, tus tareas saltan de un hilo a otro entre una suspensión y la siguiente, y una tarea dormida no está en ninguna pila: es un valor aparcado en el heap. Las tres herramientas que dabas por descontadas —el backtrace, el razonamiento por hilo, el breakpoint— fallan a la vez, y no por un defecto del tooling, sino porque async reificó el flujo de control en datos. Depurar async empieza por entender por qué las viejas herramientas mienten.

La pila muestra al executor, no a tu lógica

En código síncrono, capturar un backtrace es capturar la verdad: cada marco es una llamada viva, y leerlos de abajo arriba reconstruye “main llamó a atender, que llamó a consultar”. Esa cadena existe porque una llamada síncrona se apila y no se desapila hasta retornar. En async no ocurre nada de eso. Recuerda la máquina de estados del nivel 32: un async fn se compila a un Future que, al llegar a un .await cuyo dato aún no está listo, devuelve Poll::Pending hacia arriba hasta el executor. La pila del sistema operativo se desapila por completo en cada suspensión y vuelve al bucle de sondeo del runtime.

use tracing::info;

async fn atender(id: u64) {
    let datos = consultar(id).await; // aqui la pila del SO vuelve al executor
    info!(bytes = datos.len(), "consulta lista");
}

Si capturas un backtrace dentro de consultar, hacia arriba no verás atender seguido de quien lanzó la tarea. Verás algo así:

   3: consultar::{{closure}}
   4: <consultar::Future as Future>::poll
   5: atender::{{closure}}
   6: <tokio::runtime::task::...>::poll
   7: tokio::runtime::scheduler::multi_thread::worker::run
   8: std::sys::backtrace::__rust_begin_short_backtrace

Tu marco está envuelto en poll, y por encima solo hay executor y hilo trabajador. Quién hizo spawn de esta tarea y quién la está esperando no aparecen por ningún lado: esa relación lógica —la que en síncrono era la pila— ahora vive dispersa en las estructuras del runtime, no en el hilo. El backtrace no miente sobre el instante presente; miente sobre la historia, porque la historia de una tarea async no cabe en una pila que se desapila mil veces por segundo.

flowchart TD
A[Backtrace capturado dentro del await] --> B[poll de tu future]
B --> C[poll de la maquina de estados generada]
C --> D[bucle del executor]
D --> E[hilo trabajador del runtime]
F[Quien hizo spawn de la tarea] -.no aparece.-> A
G[Quien te espera con await] -.no aparece.-> A
style A fill:#f38ba8,color:#11111b
style D fill:#89b4fa,color:#11111b
style F fill:#45475a,color:#cdd6f4
style G fill:#45475a,color:#cdd6f4

La tarea salta de hilo entre suspensiones

El segundo pilar que se derrumba es “un flujo de ejecución vive en un hilo”. El runtime multihilo de Tokio usa un planificador con robo de trabajo: un hilo trabajador ocioso roba tareas de la cola de otro para no quedarse quieto. La consecuencia es que una tarea sondeada en el trabajador 2 puede, tras un .await, reanudarse en el trabajador 5. No hay ninguna afinidad entre una tarea y un hilo.

async fn procesar() {
    // Puede estar corriendo en el worker 2...
    let x = fase_uno().await;
    // ...y despues de este await, reanudarse en el worker 5.
    fase_dos(x).await;
}

Esto pulveriza cualquier razonamiento basado en el identificador de hilo. Un log que imprime el thread id para “seguir” una operación es inútil: la misma tarea aparecerá bajo tres identificadores distintos a lo largo de su vida. Un thread_local! observado antes y después de un .await puede haber cambiado de valor sin que tú tocaras nada, porque ya no es tu hilo. Y es precisamente por esta migración por lo que el compilador exige que todo lo que cruce un .await sea Send: la tarea podría mudarse de hilo en ese punto, y un dato !Send viajando entre hilos sería justo la carrera de datos que Rust prohíbe. La regla que el nivel 30 te presentó como una restricción de tipos es, vista desde aquí, la sombra de un hecho de ejecución: tus tareas son nómadas.

El breakpoint congela un hilo, no una tarea

El tercer golpe es el más desconcertante. Un breakpoint detiene un hilo; pero la mayoría de tus tareas, en cualquier instante, no están corriendo en ningún hilo: están dormidas, aparcadas como valores a la espera de que un waker las despierte. Una tarea suspendida es la máquina de estados en reposo, guardada en una estructura del runtime, sin marco de pila, sin registros, sin nada que un depurador tradicional sepa inspeccionar.

Poner un breakpoint en consultar y esperar a “ver el flujo” caza un fotograma arbitrario de una de las mil tareas que pasaban por ahí, arrancada de su contexto. Y lo que de verdad quieres saber cuando algo va mal —¿qué tarea está atascada?, ¿en qué .await se durmió?, ¿por qué su waker no la despierta?— es exactamente lo que un depurador de pila no puede contarte, porque la respuesta no está en ninguna pila. Está en la población de tareas dormidas que el runtime administra y que ninguna herramienta clásica sabe mirar.

Entonces, cómo se depura async

Si las tres herramientas clásicas fallan a la vez, el resto del nivel las reemplaza una por una, y siempre en la misma dirección: dejar de leer la pila y empezar a observar la tarea.

• tracing (lección 2) reconstruye la historia que el backtrace perdió: spans y events que siguen a la tarea aunque salte de hilo.
• tokio-console (lección 3) da la vista de población que ninguna pila contiene: cada tarea, su tiempo y sus wakeups, en vivo.
• Deadlocks y stalls (lección 4) enseña a leer el silencio de un .await que no vuelve, con timeout y los volcados de tareas.
• Profiling (lección 5) mide lo que de verdad importa en async: el poll time, la latencia que una tarea reparte a las demás, no el porcentaje de CPU.

Ninguna es un parche sobre el depurador roto; todas operan en la capa a la que async trasladó la verdad. Este primer capítulo era el diagnóstico. Los cuatro siguientes son el tratamiento.