fix(go): improve version fetching logic to support deeply nested sub-modules

[roele]

Currently go backend version resolution has issues with deeply nested sub-modules. For example a ls-remote go:github.com/go-kratos/kratos/cmd/kratos/v2 shows 1.x versions even though go list -versions returns no versions. This is due to the fact that mise does a root-first lookup at github.com/go-kratos/kratos while also dropping the /v2 suffix. Installation of such sub-modules will then fail trying to install the resolved latest 1.x version where instead they should pass latest.

This PR is changing the version lookup behaviour to following:

Before:
mise-debug ls-remote go:github.com/go-kratos/kratos -> 1.x
mise-debug ls-remote go:github.com/go-kratos/kratos/v2 -> 2.x
mise-debug ls-remote go:github.com/go-kratos/kratos/cmd/kratos/v2 -> 1.x

After:
mise-debug ls-remote go:github.com/go-kratos/kratos -> 1.x
mise-debug ls-remote go:github.com/go-kratos/kratos/v2 -> 2.x
mise-debug ls-remote go:github.com/go-kratos/kratos/cmd/kratos/v2 -> No versions

[gemini-code-assist]

Code Review

This pull request improves Go module version resolution, specifically for deep sub-modules that do not return versions via go list -versions. It ensures that when latest is requested for such modules, the installation correctly uses the @latest tag rather than resolving to a parent module's version. The changes include a refactored fetch_go_module_versions helper, updated installation logic, and new E2E and unit tests. Feedback was provided regarding potential performance optimizations through caching and a suggestion to use is_some_and for more idiomatic Rust code.

[Copilot]

Pull request overview

Improves Go module version resolution for deeply nested sub-modules so that modules with no tagged versions don’t incorrectly inherit parent module versions (allowing installs to proceed using @latest).

Changes:

• Add an “exact module path first” lookup for go list -m -versions and treat a successful response with no versions as authoritative.
• Adjust install behavior to preserve @latest for deep modules that report zero versions, avoiding installing an unrelated parent module’s resolved version.
• Add parsing tests for go list -json output without a Versions field and extend e2e coverage for a deep sub-module case.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/backend/go.rs	Adds a reusable version-fetch helper and updates lookup/install logic to correctly handle deep sub-modules with no versions.
e2e/backend/test_go_install_slow	Updates Go toolchain version used by the test and adds an e2e assertion covering deep sub-module @latest install behavior.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[greptile-apps]

Greptile Summary

This PR fixes version fetching for deeply nested Go sub-modules (e.g. github.com/go-kratos/kratos/cmd/kratos/v2) where go list -versions returns an empty list but the old code fell through to a parent-path lookup and returned misleading 1.x versions, causing installs to fail.

Key changes:

• _list_remote_versions now probes the exact module path first via a new fetch_go_module_versions helper. If that call succeeds but returns an empty version list, it returns immediately — treating the empty result as authoritative — instead of falling back to a parent path that may have unrelated versions.
• fetch_go_module_versions caches go list -versions results via a DashMap-backed CacheManager (disk-persisted, keyed on a hash of the module path), avoiding duplicate network calls within a session.
• A belt-and-suspenders guard in install_version_ resets the install target to @latest if the resolved version conflicts with an empty version list for the exact module path.
• GoModInfo.versions gains #[serde(default)] so that responses without a Versions field (the real-world case for deep sub-modules) deserialize correctly instead of erroring.
• Two unit tests and one slow e2e test cover the new behaviour.

Confidence Score: 4/5

Safe to merge after addressing the DashMap lock-across-await concern; the core logic fix is correct and well-tested.

The version-fetching logic fix is correct and the new e2e test validates the primary scenario. Two P2 findings remain: a DashMap RefMut held across an async await point (holding a shard lock for the full go list subprocess duration, which can stall parallel installations) and a redundant .to_string() allocation in the hash call. The await-point lock-hold is the more material concern given mise's parallel tool-installation capability.

src/backend/go.rs — specifically the fetch_go_module_versions method where the DashMap shard lock is held across the async get_or_try_init_async call.

Important Files Changed

Filename	Overview
src/backend/go.rs	Core fix: adds an exact-path go list -versions check in _list_remote_versions before falling back to parent-path heuristics, preventing deep submodule paths from inheriting parent module versions. Introduces a per-instance DashMap<String, CacheManager> to cache results; however, the RefMut from DashMap::entry().or_insert_with() is held across an async await point, holding the shard lock for the duration of the subprocess and reducing parallelism.
e2e/backend/test_go_install_slow	Updates Go version pin from 1.22 to 1.24 and adds an end-to-end test asserting that a deep submodule (github.com/go-kratos/kratos/cmd/kratos/v2@latest) installs and runs correctly.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["_list_remote_versions(tool_name)"] --> B["fetch_go_module_versions(exact path)"]
    B --> C{Result?}
    C -- "Ok(Some(versions))" --> D["return Ok(versions)\n(empty or non-empty)"]
    C -- "Ok(None) — go list failed" --> E["Build parent-path indices\n(root-first heuristic)"]
    E --> F["for each parent path\n(skip exact tool_name)"]
    F --> G["fetch_go_module_versions(parent path)"]
    G --> H{Result?}
    H -- "Ok(Some(versions))" --> I["return Ok(versions)"]
    H -- "Ok(None)" --> F
    F -- "exhausted" --> J["return Ok([])"]

    subgraph fetch_go_module_versions
        K["DashMap entry\nor_insert_with CacheManager"] --> L["get_or_try_init_async"]
        L --> M["go list -mod=readonly -m -versions -json"]
        M -- "Error" --> N["Ok(None)"]
        M -- "Success" --> O["parse GoModInfo"]
        O --> P["Ok(Some(versions))"]
    end

Loading

_{Reviews (3): Last reviewed commit: "fix(go): improve version fetching logic ..." | Re-trigger Greptile}