What causes "Installation stopped. Reason: {:?}" in windmill-labs/windmill?

Check the `{:?}` reason in the message: if it is a timeout, increase the job timeout or reduce dependency set size

Installation stopped. Reason: {:?}

Error message

Installation stopped. Reason: {:?}

What it means

When installing language dependencies (pip/npm/etc.), Windmill spawns each installation task inside a `tokio::select!` that races the actual install future against a kill-channel receiver. If a `TaskKiller` signal (timeout, job cancellation, worker shutdown) arrives on `kill_rx` before the install finishes, the spawned task returns this error reporting the kill reason. It is the normal outcome of an aborted dependency install, not a bug in the package manager itself.

Source

Thrown at backend/windmill-worker/src/universal_pkg_installer.rs:710

            dep,
            installer_executable_name.to_owned(),
            job_id.clone(),
            w_id.to_owned(),
            worker_name.to_owned(),
            conn.to_owned(),
            counter_arc.clone(),
            total_to_install,
            name_ml,
            action,
            _language_name.to_owned(),
            _platform_agnostic,
            permit,
            TaskKiller(kill_tx),
            post_install_c,
        );
        handles.push(tokio::spawn(async move {
            tokio::select! {
                reason = kill_rx.recv() => return Err(anyhow::anyhow!("Installation stopped. Reason: {:?}", reason)),
                r = task_fut => return r
            };
        }));
    }

    Ok((handles, closer))
}
/// Do not drop the returned sender! As soon as you drop it the polling thread will stop
pub async fn listen_to_cancel(
    job_id: Uuid,
    w_id: String,
    conn: Connection,
    killpill: tokio::sync::broadcast::Sender<String>,
) -> tokio::sync::broadcast::Sender<()> {
    let (close_tx, mut close_rx) = tokio::sync::broadcast::channel::<()>(1);
    tokio::spawn(async move {
        'outer: loop {
            tokio::select! {

View on GitHub (pinned to e474e8803c)

Solutions

Check the `{:?}` reason in the message: if it is a timeout, increase the job timeout or reduce dependency set size
If the job was cancelled intentionally, no action needed — re-run the job
Pin/pre-warm dependencies (lockfiles, cached lock requires) so installs finish faster and are less likely to be killed
Verify worker stability/network to registry — slow downloads make timeouts likelier

Defensive patterns

Strategy: try-catch

Try / catch

match result {
  Err(e) if e.to_string().contains("Installation stopped") => {
    // inspect the Reason in the message; treat as cancellation, optionally re-run
  }
  r => r?,
}

Prevention

Set job timeouts generously for heavy dependency installs
Use lockfiles/cached requires to shorten install time
Avoid cancelling jobs mid-install unless necessary
Ensure worker stability during long installs

When it happens

Trigger: A job that triggered `par_install_language_dependencies_all_at_once` or `par_install_language_dependencies_seq` is cancelled, times out, or the worker is shutting down while dependency installation (e.g. `pip install`, `bun install`) is still in flight; the kill signal races ahead of the install future.

Common situations: Long pip installs exceeding the job timeout, users cancelling a running flow/script, worker restarts or dedicates being killed mid-install, kill switch triggered by the worker supervisor.

Related errors

AI-assisted analysis of windmill-labs/windmill@e474e8803c (2026-09-03). Data as JSON: /api/errors/358aa28811b1fc8b. Report an issue: GitHub.