Tareas que sobreviven al comando

Lanzar, y qué llevarse

#[tauri::command]async fn empezar_indexado(app: tauri::AppHandle) -> Result<(), ErrorPayload> {    let app = app.clone();                       // clonar: es barato. Nivel 16.3    tauri::async_runtime::spawn(async move {        // el estado se pide desde dentro, con el manejador        let cache = app.state::<CachePortadas>();        for (hechos, total) in indexar().await {            let _ = app.emit(eventos::INDEXADO_PROGRESO, (hechos, total));        }    });    Ok(())                                        // el comando vuelve enseguida}

Tres cosas de ese patrón:

• El manejador se clona y se mueve dentro. Es lo único que hace falta llevarse: con él se llega al estado, a las ventanas, a los eventos y a las rutas.
• El estado no se lleva prestado. Un State inyectado tiene un tiempo de vida atado al comando, así que no puede viajar a una tarea que le sobrevive. Se pide desde dentro, con el manejador.
• El comando vuelve enseguida. Y ahí está la decisión que hay que tomar a propósito, porque cambia el manejo de errores del nivel 21.2: la promesa se resuelve antes de que el trabajo esté hecho.

Cómo informar

El criterio es el del nivel 21.1, y aquí tiene una forma concreta:

La conclusión práctica: si puedes esperar, espera. Un comando que no vuelve hasta terminar es más simple en los dos lados y no necesita eventos ni correlación. La tarea de fondo se justifica cuando el trabajo de verdad sobrevive a la interacción: una sincronización, un indexado que sigue mientras el usuario trabaja.

Las cuatro preguntas

Antes de lanzar la primera, conviene tener las cuatro respuestas escritas:

La tarea huérfana

Es lo que queda cuando faltan esas respuestas, y tiene tres consecuencias que aparecen en este orden:

Consume mientras el usuario cree que no. Cierra la ventana, la aplicación queda en la bandeja, y sigue leyendo disco. En un portátil eso es batería.

Escribe cuando nadie lo espera. Una tarea que sigue viva después de que el usuario haya cerrado un proyecto puede escribir sobre él minutos después. Combinado con que otra parte haya abierto otro proyecto, produce corrupción difícil de atribuir.

Impide cerrar. Si el apagado espera a las tareas —que es lo correcto, nivel 25.4— una tarea que no se puede parar hace que la aplicación tarde en cerrarse o no se cierre.

La defensa es la primera pregunta: toda tarea de fondo se registra en un sitio donde se la pueda encontrar y parar. Es el estado de trabajos del nivel 21.3, y no es opcional en cuanto haya más de una.