jdx/mise · error

missing arg order for {}

Error message

missing arg order for {}

What it means

The companion assertion to the runtime-build panic: after the helper thread runs the OAuth future, `.join()` re-attaches it and asserts the thread did not panic. A JoinError here means the spawned thread died — most commonly because the inner `expect("failed to build tokio runtime")` fired (resource exhaustion), or because the future itself panicked during GitHub OAuth (device flow / token refresh). The original panic is swallowed by the join, so this expect's message is what surfaces.

Source

Thrown at src/task/task_script_parser.rs:645

        if scripts_have_template {
            for script in scripts {
                if contains_template_syntax(script) {
                    let _ = Self::render_script_with_context(&mut tera, script, &tera_ctx);
                }
            }
        }
        let mut cmd = usage::SpecCommand::default();
        // TODO: ensure no gaps in args, e.g.: 1,2,3,4,5
        let arg_order = arg_order.lock().unwrap();
        cmd.args = input_args
            .lock()
            .unwrap()
            .iter()
            .cloned()
            .sorted_by_key(|arg| {
                arg_order
                    .get(&arg.name)
                    .unwrap_or_else(|| panic!("missing arg order for {}", arg.name.as_str()))
            })
            .collect();
        cmd.flags = input_flags.lock().unwrap().clone();

        // Check for deprecated Tera template args usage
        Self::check_tera_args_deprecation(&task.name, &cmd.args, &cmd.flags);

        let mut spec = usage::Spec::default();
        spec.cmd = cmd;
        spec.merge(spec_from_field);

        Ok(spec)
    }

    pub(super) async fn parse_run_scripts(
        &self,
        config: &Arc<Config>,
        task: &Task,

View on GitHub (pinned to 6f52dcdf99)

Solutions

1. Free resources and retry — raise `ulimit -n`/`ulimit -u`, relax container pids/memory limits
2. Restart the mise daemon (`mise daemon stop`) to clear leaked fds/threads, then retry
3. Run with `RUST_BACKTRACE=1` — the swallowed inner panic usually still prints first and names the real cause
4. Update mise; if the inner panic is OAuth logic rather than resource exhaustion, report it with the trace

Example fix

# before
$ mise use -g node   # panicked: tokio runtime thread panicked
# after
$ RUST_BACKTRACE=1 mise daemon stop; ulimit -n 4096; mise use -g node

mise_cmd() { RUST_BACKTRACE=1 mise "$@"; rc=$?; if [ $rc -ne 0 ] && [ $rc -lt 128 ]; then sleep 2; mise "$@"; else return $rc; fi; }  # one retry after freeing resources

When it happens

Trigger: Same conditions as the spawned-thread runtime-build failure (ENOMEM/EMFILE/thread-limit when building the current-thread runtime), or a panic inside the OAuth future running on the spawned thread while a tokio Handle is already current in the caller (mise invoked from inside another async process).

Common situations: Resource-starved CI runners and containers (low fd/thread/memory limits); invoking mise from within another tokio-based tool; mise OAuth code regressions that only panic when an ambient runtime exists.

Related errors

• semaphore closed
• BootstrapPart values have clap names
• bootstrap command is registered
• affected project exists in graph
• Unknown shim mode

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