Cancelacion: cancelar es dropear el future

Ya has cancelado futures sin darte cuenta: cada rama perdedora de un select!, cada timeout que vence, cancela trabajo. Ahora toca nombrar el mecanismo, porque es a la vez de una simplicidad asombrosa y de una peligrosidad sutil. En Rust async no existe una señal de cancelación en el lenguaje, ni un método cancel(), ni una excepción que se lance para desmontar la pila. Cancelar una operación es, literalmente, dropear su future: dejar de sondearlo y destruir el valor. Esto tiene una consecuencia exacta que hay que grabarse a fuego: al dropear un future pausado en un .await, corren los destructores de todo lo que estaba vivo en ese punto —los Drop, los guardas RAII, la liberación de buffers—, pero el código que venía después de ese .await nunca se ejecuta. La operación se corta en seco en la costura donde estaba suspendida. Entender qué corre y qué no es entender por qué cancelar en el punto equivocado puede dejar tu programa a medias.

Cancelar es dropear

En un lenguaje con hilos, cancelar es un problema espinoso: no puedes matar un hilo de forma segura a mitad de camino, porque no controlas dónde se interrumpe. Rust async lo resuelve dándole la vuelta: como un future es un valor —una máquina de estados perezosa—, para cancelarlo basta con lo que ya sabes hacer con cualquier valor: dejar de usarlo y dejarlo caer. No hay API especial; hay Drop.

async fn trabajo() -> u32 { /* varias etapas con .await */ 0 }

async fn con_limite() {
    // timeout conduce el future; si vence el plazo, DROPEA trabajo().
    // Ese drop ES la cancelacion. No hay nada mas.
    match tokio::time::timeout(Duration::from_secs(2), trabajo()).await {
        Ok(v) => usar(v),
        Err(_) => eprintln!("cancelado por timeout"),
    }
}

Todas las formas de cancelar se reducen a esto. Un select! dropea las ramas perdedoras. Un timeout dropea el future envuelto al vencer. Si guardas un future en una variable y no lo .await, y la variable sale de ámbito, se dropea sin haber corrido —cancelado antes de empezar—. Cancelar no es un evento que le mandas al future: es lo que le ocurre cuando dejas de conducirlo.

Qué corre y qué no: destructores sí, código tras await no

Esta es la sección que hay que interiorizar, porque de ella se derivan todos los aciertos y todos los errores. Un future pausado en un .await es una máquina de estados que guarda, entre sus datos, las variables locales que siguen vivas en ese punto. Al dropearlo, esas variables se destruyen —sus Drop corren—, pero la ejecución no se reanuda: el código posterior al .await simplemente no llega a existir.

struct Guardia;
impl Drop for Guardia {
    fn drop(&mut self) { println!("limpieza"); } // ESTO corre al cancelar
}

async fn tarea() {
    let _g = Guardia;          // vivo a traves del await
    algo().await;              // si se cancela AQUI...
    println!("terminado");     // ...esta linea NO corre
} // ...pero _g se dropea: se imprime "limpieza"

Si tarea se cancela mientras espera en algo().await, verás limpieza pero nunca terminado. El destructor de _g es una promesa que Rust cumple pase lo que pase, porque Drop es parte de destruir el valor. Pero println!("terminado") es código de continuación, y la continuación de un future cancelado no se ejecuta. La lección: lo que pongas en un Drop está a salvo de la cancelación; lo que pongas como código normal tras un .await, no.

Aquí conviene desmontar un reflejo heredado de otros lenguajes. En Java, Python o JavaScript, el bloque finally corre pase lo que pase —incluso si una excepción desmonta la pila—, así que se convierte en el hogar natural de la limpieza. En Rust async no hay un finally que la cancelación respete: el código que escribas después de un .await, aunque parezca de cierre, es continuación y por tanto es lo primero que se pierde al cancelar. El único mecanismo que la cancelación honra es Drop. Por eso la limpieza robusta en async no se escribe como pasos finales de la función, sino como el Drop de un guarda RAII: es la traducción de “esto debe correr pase lo que pase” al único idioma que la cancelación entiende.

El punto malo: cancelación e invariantes

Ahora el peligro. Como el código tras el .await no corre al cancelar, si una operación consta de varios pasos que deben ocurrir juntos y hay un .await entre ellos, cancelar justo ahí deja el trabajo a medias. Los destructores corren, sí, pero un invariante lógico no es un destructor.

async fn transferir(a: &Cuenta, b: &Cuenta, monto: u64) {
    a.restar(monto).await;   // paso 1: el dinero sale de a
    // <-- si se cancela AQUI, el dinero se esfumo:
    //     restado de a, jamas sumado a b. Ningun Drop lo arregla.
    b.sumar(monto).await;    // paso 2: nunca corre si cancelaron antes
}

Ningún Drop compensa esto por sí solo, porque “sumar a b” no es liberar un recurso, es lógica de negocio que vivía después del .await fatídico. El problema no es la cancelación en abstracto: es que el punto de suspensión cayó en medio de una operación que debía ser atómica. La misma disciplina que aplicabas a la cancel-safety de select! reaparece aquí en su forma más general: cada .await es un punto donde tu future puede morir, así que ningún .await debería quedar atrapado en mitad de una mutación que, interrumpida, rompa una invariante.

Estrategias: RAII, spawn y tokens

La primera defensa es mover la lógica crítica de limpieza a un Drop, para que corra aunque cancelen. Un guarda de compensación que revierte el paso 1 si no se llegó a confirmar:

struct Rollback<'a> { cuenta: &'a Cuenta, monto: u64, hecho: bool }

impl Drop for Rollback<'_> {
    fn drop(&mut self) {
        if !self.hecho { self.cuenta.revertir_sincrono(self.monto); } // corre al cancelar
    }
}

let mut guarda = Rollback { cuenta: a, monto, hecho: false };
a.restar(monto).await;
b.sumar(monto).await;
guarda.hecho = true; // llegamos al final: no hay que revertir

Fíjate en un matiz importante: la reversión vive en Drop, que es síncrono —no puede tener .await—. Si tu compensación necesitara esperar (una escritura a la base de datos), Drop no basta y tendrías que recurrir a un token cooperativo o a spawn de una tarea de limpieza; es una de las razones por las que evitar el punto malo de entrada casi siempre gana a repararlo después.

La segunda: si un trabajo debe completarse pase lo que pase, sácalo de la zona cancelable con tokio::spawn. Una tarea spawneada es desatada; ni un select! que la lanzó ni un timeout la matan al soltar sus futures. Pagas el precio de siempre —Send + 'static, sin préstamos del ámbito— a cambio de que corra hasta el final. La tercera, para cancelación cooperativa y ordenada, es un CancellationToken (de tokio_util): el future comprueba el token en puntos seguros y hace su limpieza a conciencia antes de salir, en vez de morir en un .await cualquiera.

loop {
    tokio::select! {
        _ = token.cancelled() => { limpieza_ordenada().await; break; }
        trabajo = cola.recv() => procesar(trabajo).await,
    }
}

Las tres no compiten, se combinan según qué garantías necesites. Para soltar recursos limpiamente, RAII basta y actúa siempre. Para que un trabajo no se interrumpa jamás, spawn lo desata del ámbito cancelable. Para un apagado ordenado y a tiempo, el CancellationToken convierte la cancelación en un punto explícito y controlado, donde tú eliges dónde limpiar en vez de dejarlo al azar del .await en que te sorprenda el drop. La pregunta que las ordena es simple: ¿qué debe seguir siendo cierto si esta operación muere ahora mismo?

flowchart TB
A[Future pausado en un await] --> C[Se cancela se dropea]
C --> D1[Corren los destructores de lo vivo RAII locks buffers]
C --> D2[El codigo tras el await NO se ejecuta]
D2 --> R[Riesgo invariante a medias si el punto era malo]
R --> F1[Defensa limpieza en Drop compensatorio]
R --> F2[Defensa spawn si debe completarse]
style D1 fill:#a6e3a1,color:#11111b
style D2 fill:#f38ba8,color:#11111b
style R fill:#fab387,color:#11111b