jdx/mise · error

incompatibility was identified

Error message

incompatibility was identified

What it means

In remote session setup, when both the local-mise attempt and the official artifact fallback fail, the error message unwraps `local_incompatibility.expect("incompatibility was identified")`. The invariant is that this branch is only reachable when a local incompatibility was previously detected and stored; a panic means the failure branch was entered without recording that cause.

Solutions

1. Check why the local mise run failed on the remote (permissions, arch, missing libs) — the panic masks the root cause
2. Verify the official mise artifact is downloadable from the remote (network/proxy/firewall)
3. Change the code to fall back to a generic message when local_incompatibility is None

Example fix

// before
local_incompatibility.expect("incompatibility was identified"),
// after
local_incompatibility.as_deref().unwrap_or("no incompatibility recorded"),

// pre-check before remote setup
ssh host 'uname -m' && curl -fsSL https://mise.jdx.dev/mise-latest-$(uname -s)-$(uname -m) -o /dev/null

let cause = local_incompatibility.as_deref()
    .unwrap_or("local mise failed without a recorded incompatibility");

When it happens

Trigger: Reaching the dual-failure error path at src/system/remote.rs:1009 (local mise fails to run on the remote AND the official mise artifact fallback fails) when `local_incompatibility` was never set — e.g. a code path reports failure for a reason other than detected incompatibility (network error, auth failure).

Common situations: SSH/network failures misclassified as incompatibility; remote mise binary present but broken (bad ELF, wrong arch) causing the local attempt to fail without an incompatibility record; mise artifact download blocked by a proxy, hitting the fallback-failure branch.

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

• a provided source resolves to a path
• a validated copy_link has a staged parent
• affected project exists in graph
• an operation record always has an operation
• attestation requests must not have a streaming body

AI-assisted analysis of jdx/mise@533346cc37 (2026-09-17). Data as JSON: /api/errors/7c2c269b30ee1584. Report an issue: GitHub.

Appendix: source

Thrown at src/system/remote.rs:1009

            ))
        } else {
            validate_default_binary_compatibility(session, &local, &platform.os)
                .await
                .err()
                .map(|error| format!("{error:#}"))
        };
        if local_incompatibility.is_none() {
            local
        } else {
            artifacts
                .resolve(&platform, &local)
                .await
                .wrap_err_with(|| {
                    format!(
                        "local mise could not run on remote host '{}' ({}) because {}; official mise {} artifact fallback also failed",
                        session.host.name,
                        platform.description(),
                        local_incompatibility.expect("incompatibility was identified"),
                        env!("CARGO_PKG_VERSION"),
                    )
                })?
        }
    };
    let remote = match &session.host.install_mise {
        // A dry run stays inside the staging directory it already cleans up.
        Some(install_mise) if dry_run => {
            let target = resolve_remote_install_path(session, install_mise).await?;
            info!("would install mise to {} on {}", target, session.host.name);
            stage_mise(session, &binary, staging).await?
        }
        Some(install_mise) => {
            let target = resolve_remote_install_path(session, install_mise).await?;
            install_remote_mise(session, &binary, &target).await?;
            target
        }
        None => stage_mise(session, &binary, staging).await?,

View on GitHub (pinned to 533346cc37)