infrequent crash when some tool is absent (racy crash?)

[mrzor]

This is not perfectly reproducible i.e. there might be a race somewhere.

mise version -J

{
  "version": "2025.5.17 linux-x64 (2025-05-31)",
  "latest": "2025.5.17",
  "os": "linux",
  "arch": "x64",
  "build_time": "2025-05-31 16:25:36 +00:00"
}

I initially believe that capturing the output of mise had something to do with the issue, but in practice just doing some nonsense mise which triggers the issue. I've seen one issue in CI where a stub points to an uninstalled tool producing the same error/location.

On my workstation:

○ mise which --tool gpg2@latest gpg2
=== Async Backtrace (panic occurred in tokio runtime) ===
  0: Location { name: Some("mise::toolset::Toolset::resolve::{{closure}}"), rest: ("src/toolset/mod.rs", 152, 5) }

------- TASK DUMP TREE -------
╼ mise::toolset::Toolset::resolve::{{closure}} at src/toolset/mod.rs:152:5
=== End Async Backtrace ===

The application panicked (crashed).
Message:  task 194 was cancelled
Location: /cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tokio-1.45.1/src/task/join_set.rs:439

Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.

Managed to capture a full backtrace as well, but it's not terribly informative without symbols. In this one we witness the expected error message to show out before the backtrace shows up (and presumably, exit code 101):

◎ mise which --tool gpg2@latest gpg2
mise ERROR [--runtime] gpg2@latest: gpg2 not found in mise tool registry
mise ERROR gpg2 not found in mise tool registry
mise ERROR Run with --verbose or MISE_VERBOSE=1 for more information
=== Async Backtrace (panic occurred in tokio runtime) ===
[no accessible async backtrace]
------- TASK DUMP TREE -------

=== End Async Backtrace ===

The application panicked (crashed).
Message:  Pre-condition of new violated: ! short.is_empty()
Location: src/cli/args/backend_arg.rs:51

  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
                                ⋮ 8 frames hidden ⋮                               
   9: mise::cli::args::backend_arg::BackendArg::new::panic_cold_display::hd6cefb3cfb117ebe
      at <unknown source file>:<unknown line>
  10: mise::cli::args::backend_arg::BackendArg::new::h7fcfc8b0329a9c10
      at <unknown source file>:<unknown line>
  11: <mise::cli::args::backend_arg::BackendArg as core::convert::From<A>>::from::hefa2a94216654e17
      at <unknown source file>:<unknown line>
  12: <mise::cli::args::tool_arg::ToolArg as core::str::traits::FromStr>::from_str::h696dc5d67ba3006b
      at <unknown source file>:<unknown line>
  13: <F as clap_builder::builder::value_parser::TypedValueParser>::parse_ref::h8b90e442c4dc981c
      at <unknown source file>:<unknown line>
  14: <P as clap_builder::builder::value_parser::AnyValueParser>::parse_ref_::h8a827ef5ae7e5ff5
      at <unknown source file>:<unknown line>
  15: clap_builder::parser::parser::Parser::push_arg_values::hd253a0cc7b9da46e
      at <unknown source file>:<unknown line>
  16: clap_builder::parser::parser::Parser::react::h51651cebe3e0c2b7
      at <unknown source file>:<unknown line>
  17: clap_builder::parser::parser::Parser::resolve_pending::h04633e1e48c6f581
      at <unknown source file>:<unknown line>
  18: clap_builder::parser::parser::Parser::get_matches_with::hc0c5d9ae32ef9431
      at <unknown source file>:<unknown line>
  19: clap_builder::parser::parser::Parser::get_matches_with::hc0c5d9ae32ef9431
      at <unknown source file>:<unknown line>
  20: clap_builder::builder::command::Command::_do_parse::ha25faf16d8771f9f
      at <unknown source file>:<unknown line>
  21: clap_builder::derive::Parser::parse_from::hc94fa1044d7f39d7
      at <unknown source file>:<unknown line>
  22: mise::cli::Cli::run::{{closure}}::hd4f8dee9592950b2.42538<unknown>
      at <unknown source file>:<unknown line>
  23: mise::main::hcacf817c3e94a1fd
      at <unknown source file>:<unknown line>
  24: std::sys::backtrace::__rust_begin_short_backtrace::he3f5bf7081f70fcf
      at <unknown source file>:<unknown line>
  25: main<unknown>
      at <unknown source file>:<unknown line>
  26: __libc_start_main<unknown>
      at <unknown source file>:<unknown line>
  27: _start<unknown>
      at <unknown source file>:<unknown line>

Run with COLORBT_SHOW_HIDDEN=1 environment variable to disable frame filtering.

The "happy path" for that error is the classic:

mise ERROR [--runtime] gpg2@latest: gpg2 not found in mise tool registry
mise ERROR gpg2 not found in mise tool registry
mise ERROR Run with --verbose or MISE_VERBOSE=1 for more information

Finally, an observation: in CI where I saw this same error, in previous builds using an older mise we had mise WARN failed to resolve toolset errors for various reasons.

[greg0ire]

Using MISE_ENABLE_TOOLS / MISE_DISABLE_TOOLS seems to be a good workaround for this.

[mrzor]

In the sense that it prevents the error message to show up in some instances, yes. But in contexts (like on workstation) where having the error is the point, the panic remains undesirable.

[jkp]

I tracked this down to using npm:* as a tool dependency when also installing node. It looks like the dependency management stuff isn't working properly. My workaround is hacky but it works...

[hooks]
# Install global node modules here because npm tool dependencies are broken
postinstall = "npm install -g ..."

[mrzor]

Thanks for the drilldown! I'm afraid the workaround won't work for me, but I'll just do without npm:... for now

[JamBalaya56562]

Both panics in your report are fixed, though at different times — and the second one is a different bug from the first, so it's worth splitting them.

The task 194 was cancelled panic. Your async backtrace pointing at toolset/mod.rs was the real clue. Toolset::resolve runs each tool's version resolution as a task in a JoinSet, and it used to propagate a resolve failure with ?:

tvl.resolve(&config, &Default::default()).await?;

The first failing task therefore aborted the whole set, and the drain afterwards used JoinSet::join_all(), which panics when it encounters a cancelled task. So any single tool that failed to resolve — gpg2@latest not being in the registry is exactly that — turned into a panic instead of the error message you were expecting. That also explains the raciness you observed: whether you got the clean error or the panic depended on whether another task was still in flight when the abort landed.

Fixed on both layers:

• fix: only warn on toolset resolve errors #5435 (shipped in v2025.6.8) — resolve failures now warn instead of aborting the set: warn_once!("Failed to resolve tool version list for {ba}: {err}").
• feat(conda): add dependency resolution for conda packages #7280 (shipped in v2025.12.8) — the drain no longer panics on cancellation, for every parallel caller rather than just this one:

  jset.abort_all();
  // Drain remaining tasks - don't use join_all() as it panics on cancelled tasks
  while jset.join_next().await.is_some() {}

Your mise WARN failed to resolve toolset observation from older CI builds is the same event before it became fatal, which fits.

The Pre-condition of new violated: ! short.is_empty() panic. This one is unrelated to the toolset race — your backtrace shows it firing during argument parsing (clap → ToolArg::from_str → BackendArg::from), before any async work starts. BackendArg::new carries a #[requires(!short.is_empty())] contract, and the From impl used to route through it. On current main From calls new_raw directly and never touches that contract, so an empty short name can no longer abort the process there; the contract remains only on paths fed by the registry and config, where the value is non-empty by construction.

On the workarounds in this thread:

@greg0ire — MISE_ENABLE_TOOLS / MISE_DISABLE_TOOLS worked because it kept the unresolvable tool out of the set entirely. No longer needed for this.

@jkp — your postinstall = "npm install -g ..." hook shouldn't be needed either, and the npm:*-with-node ordering you suspected has since changed underneath: npm: version queries go over HTTP to the registry and installs use an embedded package manager, so node is the only hard dependency now (it's still declared, since installed JS tools need a runtime). If you drop the hook and it breaks again, that would be worth its own report with --verbose output — it would be a different bug from this one.

Everything here predates your 2025.5.17, so a straight upgrade should cover it. If you can still reproduce either panic on a current version, please do reopen — with the mise which --tool gpg2@latest gpg2 invocation, since that turned out to be a reliable trigger for you.