fix(lock): prune stale version entries during filtered mise lock <tool> runs

[altendky]

Summary

When running mise lock <tool> after a tool's resolved version changes, the old lockfile entry was preserved and a new one appended, resulting in duplicate [[tools.<tool>]] sections with different versions.

For example, if mise.toml has node = "24" and mise.lock previously resolved to 24.13.0, then after 24.14.0 becomes available and is installed, running mise lock node produces:

[[tools.node]]
version = "24.13.0"
backend = "core:node"
# ... platform entries ...

[[tools.node]]
version = "24.14.0"
backend = "core:node"
# ... platform entries ...

The expected behavior is that mise lock node should replace the stale 24.13.0 entry with the 24.14.0 entry, not append alongside it.

Cause

Two code locations interact to produce this bug:

1. Filtered lock runs skip all pruning (src/cli/lock.rs:168-176): prune_stale_entries_if_needed() returns early for filtered runs (mise lock <tool>) to avoid removing non-targeted tools. But this also prevents pruning old versions of the targeted tool itself.

2. set_platform_info matches by (version, options) (src/lockfile.rs:655-705): a version change always creates a new entry rather than updating the existing one.

Prior art

• fix(lockfile): fix multiple lockfile issues with version management #5907 fixed this same class of bug for the update_lockfiles() code path used by mise install/mise upgrade. The mise lock CLI uses a separate code path that was not covered.
• fix(lockfile): prune orphan tool entries on mise lock #8265 added pruning of stale entries to mise lock, but only for unfiltered runs and only by tool name (tools removed from config entirely), not by stale versions within a targeted tool.

Fix

• Add Lockfile::retain_tool_versions(short, keep_versions) that removes entries for a tool whose version is not in the given set.
• Add Lock::prune_stale_versions_for_targeted_tools() that, for filtered runs only, collects the current resolved versions per tool and calls retain_tool_versions before processing.
• The existing guard against pruning non-targeted tools remains intact — only versions of the targeted tool(s) are pruned.

Tests

• 4 unit tests covering: stale version pruned, current version preserved, non-targeted tools untouched, unfiltered runs skip this path.
• 1 e2e test (test_lockfile_lock_filtered_prune_stale_versions) verifying the end-to-end scenario.

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a critical bug in mise lock <tool> where updating a tool's version would result in duplicate entries in the mise.lock file instead of replacing the old version. The changes introduce a targeted pruning mechanism for filtered lock runs, ensuring that only the currently resolved version of a tool is maintained in the lockfile, thereby preventing accumulation of stale version entries and maintaining lockfile integrity.

Highlights

• Corrected mise lock <tool> behavior: Fixed a bug where mise lock <tool> would append new [[tools.<tool>]] entries for changed versions instead of replacing stale ones, leading to duplicate entries in mise.lock.
• Introduced version-specific pruning: Implemented a new mechanism to prune stale versions for targeted tools during filtered mise lock runs, ensuring only the currently resolved version is retained.
• Added retain_tool_versions to Lockfile: A new public method retain_tool_versions was added to the Lockfile struct, allowing specific tool versions to be kept while others are removed.
• Enhanced test coverage: Added new unit tests to src/cli/lock.rs and a dedicated end-to-end test to validate the corrected pruning logic for filtered mise lock runs.

Changelog

• e2e/lockfile/test_lockfile_lock_filtered_prune_stale_versions
  • Added a new end-to-end test to verify that mise lock <tool> correctly prunes stale version entries.
• src/cli/lock.rs
  • Imported BTreeMap for use in version tracking.
  • Called prune_stale_versions_for_targeted_tools before processing tools to ensure stale versions are removed.
  • Implemented prune_stale_versions_for_targeted_tools to identify and remove outdated versions for targeted tools during filtered lock runs.
  • Added four new unit tests to validate the version pruning logic, covering scenarios like pruning stale versions, preserving current versions, protecting non-targeted tools, and skipping pruning for unfiltered runs.
• src/lockfile.rs
  • Added a new public method retain_tool_versions to Lockfile to remove entries for a specific tool that are not in a given set of versions.

Activity

• No human activity (comments, reviews, etc.) has been recorded on this pull request yet.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request fixes a bug where mise lock <tool> would not prune stale version entries, leading to duplicate tool sections in the lockfile. The fix introduces a new pruning mechanism specifically for filtered lock runs, which correctly removes old versions of the targeted tool while leaving other tools untouched. The changes are well-implemented and include a comprehensive set of unit tests and a new end-to-end test to verify the fix.

My review includes one suggestion to improve the robustness of a unit test by making its assertion more specific.

[gemini-code-assist]

The assertion in this test is a bit weak. It confirms that a tool on linux-x64 still exists, but doesn't explicitly verify that dummy was pruned and jq was preserved.

To make the test more robust, you could add the jq tool on a different platform (e.g., macos-x64). This way, after pruning dummy (which is on linux-x64), you can assert that only macos-x64 remains in all_platform_keys(), which would strongly prove that dummy was removed while jq was untouched.

    #[test]
    fn test_filtered_run_preserves_non_targeted_tools() {
        // Simulate: lockfile has dummy@1.0.0 and jq@1.7.1, filter targets only dummy
        let cmd = lock_cmd(&["dummy"]);
        let mut lockfile = lockfile_with_dummy(); // has dummy@1.0.0 on linux-x64
        lockfile.set_platform_info(
            "jq",
            "1.7.1",
            Some("aqua:jqlang/jq"),
            &BTreeMap::new(),
            "macos-x64", // Use a different platform for jq
            PlatformInfo {
                checksum: Some("sha256:jq".to_string()),
                ..Default::default()
            },
        );
        // Resolve dummy to a new version; jq is not targeted
        let tools = vec![configured_tool("dummy", "2.0.0")];

        cmd.prune_stale_versions_for_targeted_tools(&mut lockfile, &tools);

        // dummy@1.0.0 (linux-x64) should be removed, jq@1.7.1 (macos-x64) should remain
        assert_eq!(
            lockfile.all_platform_keys(),
            std::collections::BTreeSet::from(["macos-x64".to_string()])
        );
    }

[altendky]

Good catch — the original assertion was indeed trivially satisfied since both tools shared linux-x64. Moved jq to macos-x64 so the assertion now proves dummy was actually pruned. Addressed in a56583bb1.

This comment was generated by Claude Code.

[greptile-apps]

Greptile Summary

This PR fixes a bug where running mise lock <tool> after a tool's resolved version changed would append a new [[tools.X]] section alongside the old one instead of replacing it. The fix adds Lockfile::retain_tool_versions to remove entries whose version is no longer current, and wires it into both filtered and unfiltered mise lock code paths with correct ordering (compute stale versions before process_tools, prune after). The logic for not touching non-targeted tools during filtered runs is preserved correctly.

Confidence Score: 5/5

Safe to merge — correct fix, well-tested, no blocking issues found.

All changes are logically sound: retain_tool_versions mirrors the established retain_tools_by_short_or_backend pattern, the ordering (compute stale before process_tools, prune after) is correct, and the guard ensuring filtered runs only touch targeted tools is intact. Six unit tests and two e2e tests cover the key scenarios including version-preservation, non-targeted-tool preservation, and both run modes. No P0 or P1 findings.

No files require special attention.

Important Files Changed

Filename	Overview
src/cli/lock.rs	Adds prune_stale_versions / stale_versions_if_pruned helpers and wires them into the dry-run and normal execution paths; ordering (compute before process_tools, prune after) is correct; unfiltered-run pruning of fully-removed tools now also shows a message; 6 new unit tests cover all key scenarios.
src/lockfile.rs	Adds retain_tool_versions (mutating) and stale_tool_versions (read-only) which mirror the existing retain_tools_by_short_or_backend / stale_tool_shorts pair; cleanup_unreferenced_conda_packages is correctly called after mutation.
e2e/lockfile/test_lockfile_lock_filtered_prune_stale_versions	End-to-end regression test for the filtered-run bug using the dummy backend; correctly asserts old version absent and new version present after a filtered re-lock.
e2e/lockfile/test_lockfile_lock_unfiltered_prune_stale_versions	End-to-end regression test for the unfiltered-run stale-version pruning (new behavior); mirrors the filtered test structure.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["mise lock [tool]"] --> B{tools.is_empty?}
    B -- Yes --> C{dry_run?}
    C -- Yes --> D[show stale tool prune message]
    C -- No --> E[prune_stale_entries_if_needed\nwrite lockfile if changed]
    B -- No --> F[determine_target_platforms]
    F --> G{dry_run?}
    G -- Yes --> H[show_dry_run\nread lockfile\nshow stale tool prune\nshow stale version prune]
    G -- No --> I[read lockfile\nprune_stale_entries_if_needed\nshow stale tool msg]
    I --> J["stale_versions = stale_versions_if_pruned\n(computed BEFORE process_tools)"]
    J --> K[process_tools\nupdate lockfile entries]
    K --> L["prune_stale_versions\n(removes old versions AFTER process_tools)"]
    L --> M[show stale version msg\nwrite lockfile]
    
    style J fill:#ffffcc
    style L fill:#ccffcc

Loading

_{Greploops — Automatically fix all review issues by running /greploops in Claude Code. It iterates: fix, push, re-review, repeat until 5/5 confidence.
Use the Greptile plugin for Claude Code to query reviews, search comments, and manage custom context directly from your terminal.}

_{Reviews (7): Last reviewed commit: "Merge branch 'main' into fix/lock-filter..." | Re-trigger Greptile}

[altendky]

Addressed the dry-run reporting gap for filtered runs (item 1 from Greptile review). mise lock <tool> --dry-run now reports which stale version entries would be pruned, matching the existing behavior for unfiltered runs. Also added reporting in the non-dry-run path for consistency.

Addressed in 2c16bda3f.

[ilyagr]

I think this might not be true. I haven't looked in detail, but

• I have the same problem with plain mise lock.
• According to AI, (I haven't double-checked, sorry)

prune_stale_entries_if_needed calls retain_tools_by_short_or_backend, which retains or removes entire tools by name — it answers "is pnpm still in the config?" If you removed pnpm from mise.toml entirely, it removes all pnpm entries from the lockfile.

But it never looks at versions within a tool. If pnpm is still configured and the lockfile has both 10.31.0 and 10.32.0, retain_tools_by_short_or_backend sees "pnpm is configured" and keeps all entries for it, duplicates and all.

[altendky]

no worry about the ai usage... it's happening here to too. gotta learn how to use the tool well.

thanks for the feedback, i'll take a look into this myself and see what turns up.

[ilyagr]

Here is a reproduction, also AI-generated. (I'm not so much apologizing for using AI as for not taking the time to make its output more readable, but if you don't already have a reproduction and want one, it shouldn't be that bad to follow)

https://gist.github.com/ilyagr/aacb2ca0ee868ba10e29f43425a4b692

[jdx]

Thanks for the fix! The core approach looks correct and well-tested. Two things to address:

1. Non-dry-run path needs an unfiltered guard

In the non-dry-run path (lines 134-136), stale_versions_if_pruned and show_stale_version_prune_message are called unconditionally — including on unfiltered runs — but prune_stale_versions_for_targeted_tools is a no-op for unfiltered runs. This means an unfiltered mise lock with a version change will print "✓ Pruned N stale version entries" without actually pruning anything.

The dry-run path correctly guards this with the else branch of is_unfiltered_lock_run(), but the non-dry-run path needs the same guard:

if !self.is_unfiltered_lock_run() {
    let stale_versions = self.stale_versions_if_pruned(&lockfile, &tools);
    self.prune_stale_versions_for_targeted_tools(&mut lockfile, &tools);
    self.show_stale_version_prune_message(lockfile_path, &stale_versions, false)?;
}

2. Unfiltered mise lock has the same version-accumulation bug

As ilyagr pointed out, unfiltered mise lock has the same stale version problem — prune_stale_entries_if_needed only removes tools deleted from config entirely, not stale versions within a tool. Since this PR is already fixing the version pruning logic, it should handle both filtered and unfiltered runs together rather than leaving one path broken.

This comment was generated by Claude Code.

[altendky]

a million monkeys may or may not have written shakespeare so far... but gosh darn it, we'll at least manage to get this pr done with 6 AIs, or whatever we're up to.

[altendky]

@jdx, i think this is ready for review whenever