What causes "querying scheduled task {task} failed: {}" in jdx/mise?

Inspect the embedded stderr message in the error for the concrete OS reason (access denied, RPC server unavailable, etc.).

jdx/mise · error

querying scheduled task {task} failed: {}

Error message

querying scheduled task {task} failed: {}

What it means

The query helper runs a PowerShell/schtasks command under a timeout and, if the process exits non-zero, wraps the trimmed stderr into this error. It distinguishes itself from the timeout case (which produces its own 'timed out' message), so this error always reflects an actual failure reported by the query command.

Source

Thrown at src/system/scheduled_tasks.rs:476

    }
    let args = [
        "-NoProfile".to_string(),
        "-NonInteractive".to_string(),
        "-Command".to_string(),
        query_script(name),
    ];
    debug!("$ powershell {}", shell_words::join(&args));
    let mut cmd = tokio::process::Command::new("powershell.exe");
    cmd.args(&args)
        .stdin(Stdio::null())
        .stdout(Stdio::piped())
        .stderr(Stdio::piped())
        .kill_on_drop(true);
    let output = tokio::time::timeout(SCHTASKS_TIMEOUT, cmd.output())
        .await
        .map_err(|_| eyre!("querying scheduled task {task} timed out"))??;
    if !output.status.success() {
        bail!(
            "querying scheduled task {task} failed: {}",
            String::from_utf8_lossy(&output.stderr).trim()
        );
    }
    Ok(parse_query(&String::from_utf8_lossy(&output.stdout)))
}

fn parse_query(output: &str) -> Option<Query> {
    let state = output.trim();
    if state.eq_ignore_ascii_case("MISSING") || state.is_empty() {
        return None;
    }
    Some(Query {
        running: state.eq_ignore_ascii_case("Running"),
        disabled: state.eq_ignore_ascii_case("Disabled"),
    })
}

View on GitHub (pinned to afd2eddd3a)

Solutions

Inspect the embedded stderr message in the error for the concrete OS reason (access denied, RPC server unavailable, etc.).
Rerun elevated or as the account that owns the task if stderr indicates access denied.
Verify schtasks/PowerShell work manually on the host; fix PATH, policy, or service issues if they fail standalone.
Handle the not-found case via exists()/status handling rather than treating every non-zero query as fatal if the task may legitimately be absent.

Defensive patterns

Strategy: try-catch

Validate before calling

// before querying, ensure the host can run schtasks:
// schtasks /Query /TN "mise\\my-task" 2>nul || echo "schtasks unavailable or access denied"

Try / catch

match query_task(task) {
    Err(e) if e.to_string().starts_with("querying scheduled task") => {
        let stderr = e.to_string();
        if stderr.contains("Access is denied") {
            // rerun elevated or skip with a warning
        } else if stderr.contains("does not exist") {
            Ok(None) // treat as absent task
        } else {
            Err(e)
        }
    }
    other => other,
}

Prevention

Check task existence via exists()/status with not-found handling instead of assuming success
Run queries with sufficient privileges for the task folder being queried
Verify schtasks/PowerShell availability on minimal Windows images before deploying services
Distinguish timeout errors (separate message) from stderr failures in your retry logic

When it happens

Trigger: Calling status, exists, or apply, which invokes query; the spawned command returns a non-success exit status — e.g. schtasks/PowerShell not available, access denied, or the task store reporting an error.

Common situations: Querying on a machine where schtasks is restricted by policy; running without elevation when the task requires it; transient WinRM/PowerShell startup failures; stderr containing localized error text that must be read to diagnose.

Related errors

AI-assisted analysis of jdx/mise@afd2eddd3a (2026-09-09). Data as JSON: /api/errors/ba9512ba5dcbd19f. Report an issue: GitHub.