jdx/mise · error

executor must be initialized before running tasks

Error message

executor must be initialized before running tasks

What it means

The task-scheduling entry point of `mise run` forwards to TaskExecutor: `self.executor.as_ref().expect("executor must be initialized before running tasks").run_task_sched(ctx)` (src/cli/run.rs:1343-1353). The executor is created earlier via setup_executor during run setup; this expect enforces ordering — scheduling must not run before initialization succeeded. It is an API-misuse guard inside the run pipeline, not a user-configurable state.

Source

Thrown at src/cli/run.rs:1351

                .executor
                .as_ref()
                .map(|e| e.is_interrupted())
                .unwrap_or(false)
    }

    fn mark_interrupted(&self) {
        if let Some(executor) = &self.executor {
            executor.mark_interrupted();
        }
    }

    async fn run_task_sched(
        &self,
        ctx: TaskRunContext<'_>,
    ) -> Result<crate::task::task_executor::TaskRunOutcome> {
        self.executor
            .as_ref()
            .expect("executor must be initialized before running tasks")
            .run_task_sched(ctx)
            .await
    }

    fn add_failed_task(&self, task: Task, status: Option<i32>) {
        if let Some(executor) = &self.executor {
            executor.add_failed_task(task, status);
        }
    }

    fn validate_task(&self, task: &Task) -> Result<()> {
        use crate::file;
        use crate::ui;
        if self.task_cache.enabled() && task.cache.as_ref().is_some_and(|cache| cache.enabled) {
            Settings::get().ensure_experimental("task artifact caching")?;
        }
        if task.rust_cache.as_ref().is_some_and(|cache| cache.enabled) {
            Settings::get().ensure_experimental("Rust action caching")?;

View on GitHub (pinned to 6f52dcdf99)

Solutions

1. If hit as a user: update mise; the run flow in that build invokes scheduling before initialization
2. As a contributor: call setup_executor() (and fail on its Err) before any code path that can reach run_task_sched; consider returning a bail!("executor not initialized") instead of expect for earlier diagnostics
3. In tests/harnesses, drive the public run() entry rather than run_task_sched directly
4. Report at https://github.com/jdx/mise/issues with backtrace

Example fix

// before: scheduling reached without setup
let outcome = self.run_task_sched(ctx).await; // executor None -> panic

// after: initialize first, propagate setup errors
self.setup_executor()?;
let outcome = self.run_task_sched(ctx).await?;

When it happens

Trigger: Code that drives the task runner (run_task_sched) without having gone through the setup steps that populate self.executor — e.g. a new subcommand or test harness wiring TaskRunContext directly, or a refactor reordering setup. Ordinary `mise run` invocations initialize the executor first or fail during setup.

Common situations: Contributors adding alternate entry points to task execution; embedders reusing the run pipeline in tests. Unlike mark_interrupted/add_failed_task just above (which gracefully tolerate None), run_task_sched hard-requires the executor because it cannot do anything without it.

Understand the failure class

Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.

Related errors

• task executor initialized
• executor must be initialized before displaying cache stats
• enabled accounts were prepared
• configured notifications came from managed files
• configured notifications prepared services

AI-assisted analysis of jdx/mise@6f52dcdf99 (2026-08-22). Data as JSON: /api/errors/c8dbb02ef2d0d6ef. Report an issue: GitHub.