Greptile Summary

This PR fixes two root-cause bugs behind stale literal install directories: resolve_prefix no longer falls back to the literal prefix string when remote returns no matches, and is_version_installed now detects when a request path (e.g., installs/<id>/latest/) differs from the resolved concrete version, forcing a real reinstall instead of a silent no-op. Supporting changes add a one-time migration to rewrite existing stale dirs into runtime symlinks and extend rebuild_symlinks_in_dir to self-heal stale real dirs during normal runtime rebuilds.

Confidence Score: 4/5

Safe to merge with two minor P2 items; no blocking correctness issues remain.

All remaining findings are P2: a narrower channel-dir filter in the latest_installed_version fallback (functionally benign due to sort order but worth hardening) and a migration test that only checks marker creation without exercising an actual stale-dir rewrite. Core logic in resolve_prefix, is_version_installed, rebuild_symlinks_in_dir, and migrate_real_dirs_in_dir is correct and the new e2e tests cover the primary failure modes.

e2e/tools/test_runtime_symlink_migration — test does not exercise stale-dir migration; src/backend/mod.rs — latest_installed_version fallback filter.

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[mise install / upgrade] --> B{ToolRequest type?}
    B -->|Version / Prefix| C[request.install_path]
    C --> D{path exists?}
    D -->|No| G[check tv.install_path\nresolved concrete path]
    D -->|Yes| E{request basename\n== tv.version?}
    E -->|Yes| F[✓ already installed]
    E -->|No — stale dir| G
    G --> H{concrete path exists?}
    H -->|Yes| F
    H -->|No| I[run backend install hook\nwrites installs/id/2.0.0/]

    J[startup / mise run] --> K[migrate_runtime_symlink_dirs\none-time, marker gated]
    K --> L[migrate_real_dirs_in_dir\nfor each backend]
    L --> M{from in\nconcrete_installs?}
    M -->|Yes| N[skip — real concrete install]
    M -->|No| O[remove_all stale dir\nmake_symlink_or_file]

    P[rebuild runtime symlinks] --> Q[rebuild_symlinks_in_dir]
    Q --> R{is_runtime_symlink?}
    R -->|Yes, wrong target| S[remove symlink → recreate]
    R -->|No — real dir| T{from_name != to_name\nAND not concrete?}
    T -->|Yes| U[remove_all stale dir → recreate]
    T -->|No| V[continue]

_{Reviews (8): Last reviewed commit: "fix(backend): preserve concrete installs..." | Re-trigger Greptile}

You should add an e2e test that fails without this change, but passes with this change. I use latest for many tools, but it upgrades fine. I don't think this is the correct way to fix.
Also, doesn't it force-reinstall even the actual latest version is the same as the current one?

I haven't looked deep but I suspect this will break shit. I'm surprised the e2e tests passed.

@risu729 @jdx — you were both right, the force: true approach was too broad. I've force-pushed a replacement commit that addresses the root cause in is_version_installed instead.

TL;DR: The early return compares tv.request.install_path() (which uses the request version like "latest") against the filesystem, but never falls through to tv.install_path() (the resolved version). An existing guard already handled this for ToolRequest::Prefix; I've extended it to ToolRequest::Version so that channel pins like @latest check the resolved path when the request dir name doesn't match the resolved version.

This answers @risu729's "doesn't it force-reinstall even when the current version is the same as the latest?" — it no longer does. force stays false on the upgrade path; the narrow guard only triggers when the request basename (e.g. "latest") genuinely differs from the resolved tv.version (e.g. "1.21.0").

It also answers why you haven't hit this with most @latest tools — the bad state (a real installs/<id>/latest/ directory instead of a symlink) only arises when the first install left tv.version set to the literal "latest", which happens when resolve falls back to the alias in resolve_prefix. Backends like aqua / vfox / core / npm rarely trip that path; the Go backend is the most exposed because sub-module paths + goproxy behavior make transient resolve failures more likely.

E2e regression test included per @risu729's request: e2e/cli/test_upgrade_latest_stale sets up the bad state with a sentinel file and asserts that mise up actually installs the new version. Full root-cause analysis and tradeoffs in the updated PR description.

oh is this why the "latest" as directory thing started happening? we definitely need to fix this

@jdx Confirmed — that's the mechanism. Three links in the chain:

1. is_version_installed short-circuit → fixed by this PR.
2. runtime_symlinks::rebuild (src/runtime_symlinks.rs:58) deliberately skips real dirs.
3. latest_installed_version (src/backend/mod.rs:855-878) returns the literal "latest" when the path isn't a symlink — that's the self-reinforcing loop: stale real dir → "latest" as a version → resolve_version re-pins tv.version = "latest" → runtime resolves back to the stale dir.

So the current PR makes install_version_ run but the stale installs/<id>/latest/ stays and wins at runtime — exactly what my e2e just caught.

Pushing a follow-up commit on this branch: after install_version_ succeeds, when the request basename ≠ resolved tv.version, replace the stale real dir at the request path with a runtime symlink to the resolved dir — using the existing make_symlink_or_file helper, ~15 LOC, Windows-safe, tight guards (only Version/Prefix request, basename mismatch, non-symlink, inside our own installs dir). The existing e2e/cli/test_upgrade_latest_stale stays as regression proof (fails today, passes after).

Two calls for you:

• Local cleanup in install_version (surgical) or extend runtime_symlinks::rebuild to self-heal existing stuck states across all tools (broader, higher blast radius)?
• Want me to also harden latest_installed_version so it refuses to return the literal alias when the path isn't a symlink? That's the longer-lived root cause, but I'd do it as a separate PR unless you'd rather bundle.

I want some time to look this over properly but should get back to you soon. Nice work identifying this.

I dug into the regression path a bit more and found the behavior split across two changes:

1. The stale real directories themselves come from an old fallback in resolve_prefix / latest resolution where we fall back to the literal request when remote matching returns no result (latest, 24, 24.0, etc.). That can leave real install dirs named after the fuzzy request instead of the resolved version.
2. The reason it started breaking users recently is dc840866 (fix(env): use runtime symlink paths for fuzzy versions). After that change, runtime PATH/bin resolution started preferring request paths like latest, 24, and 24.0, so once one of those existed as a real directory, it began winning at runtime instead of the concrete install dir.

To address both the new and existing bad states, I pushed a follow-up commit on this branch (2f01b8051):

• an install-time repair that rewrites a stale request-path dir into the correct runtime symlink after a successful resolved install
• a one-time startup migration in migrate.rs that rewrites existing stale fuzzy-version dirs into runtime symlinks and drops a marker file so it only runs once

That handles existing installs with low ongoing blast radius, which seems to match the concern here better than a perpetual broad cleanup. I also left a removal note on the migration so it can be deleted after the grace period.

Locally verified with:

• cargo check --all-features
• mise run test:e2e e2e/cli/test_upgrade_latest_stale e2e/tools/test_runtime_symlink_migration e2e/tools/test_runtime_symlinks

This comment was generated by an AI coding assistant.