mise lock silently drops all platform checksums/URLs when resolved options gain a key not yet in the lockfile

[zeitlinger]

Summary

mise lock produces a duplicate [[tools.java]] entry — one with the existing platform checksums/URLs (empty options) and one fresh entry with [tools.java.options] shorthand_vendor = "openjdk" (and no platform info). A subsequent mise lock invocation prunes the original entry as "stale", leaving the lockfile with core:java pinned to a version but with zero platform checksums or URLs. mise install --locked on any platform then breaks.

The root cause looks to be the dedup key in merge_tool_entries at src/lockfile.rs:1894:

let key = (tool.version.clone(), tool.options.clone());

When mise's java resolution starts attaching shorthand_vendor = "openjdk" to a tool that previously had no options stored in the lockfile, the new and old entries get different keys, so they don't merge — instead they coexist briefly, and the next prune cycle keeps the "fresh" (empty-platforms) one and drops the platforms-only one.

Reproduction

mise.toml:

[tools]
java = "26"

Lockfile that has been around for a while already contains the java entry with all 5 platform checksums/URLs and no [tools.java.options] block.

$ MISE_VERBOSE=1 mise lock
# ... (other tools)
INFO  lock                                java@26.0.1 linux-x64
DEBUG failed to resolve java for linux-arm64-musl: no metadata found for version 26.0.1 on linux-arm64-musl
DEBUG failed to resolve java for linux-x64-musl: no metadata found for version 26.0.1 on linux-x64-musl
INFO  lock                                java@26.0.1 macos-arm64
# ...etc

After this run mise.lock contains two [[tools.java]] entries:

[[tools.java]]
version = "26.0.1"
backend = "core:java"

[tools.java."platforms.linux-arm64"]
checksum = "sha256:12a3649b2f..."
url = "https://download.java.net/.../openjdk-26.0.1_linux-aarch64_bin.tar.gz"
# ...5 platforms in total

[[tools.java]]
version = "26.0.1"
backend = "core:java"

[tools.java.options]
shorthand_vendor = "openjdk"

The second invocation of mise lock then prunes the first entry (because the resolved tool now reports options, so the entry without options is "stale"), leaving:

[[tools.java]]
version = "26.0.1"
backend = "core:java"

[tools.java.options]
shorthand_vendor = "openjdk"

No platform info. mise install --locked on linux/x64 fails because linux-x64 is not in the lockfile.

Mise version

2026.6.12 linux-x64

Why I think this is a bug

The dedup key includes options, but the platform info is keyed on (version, platform) and is identical regardless of whether resolution attached shorthand_vendor = "openjdk". When mise gains a new option that didn't used to round-trip through the lockfile, every existing lockfile silently loses all platform data on the next mise lock.

Suggested directions

1. Make the dedup key in merge_tool_entries insensitive to options keys that are purely informational / derivable (or always merge by (version,) and union the option maps).
2. When the only difference between an existing entry and the resolved entry is that the resolved entry gained options, merge platforms from the existing entry into the new one rather than spawning a sibling.
3. Lock writer: refuse to write an entry with zero platforms while an existing platform-bearing entry for the same (version,) is being dropped — fail loudly instead of silently producing a useless lockfile.

Happy to send a PR if you can confirm the preferred direction.

Related

#10563 — separate bug (npm backend tool drops out of toolset when npm CLI absent). Same end-user symptom (broken lockfile after mise lock) but different code path.

[zeitlinger]

@risu729 can you take a look?

[risu729]

Sorry, I guess my PR caused this bug, but I don't have time now.

[zeitlinger]

I can help with a fix if you give me feedback on the suggested directions

[JamBalaya56562]

Opened a fix: #10710

Root cause confirmed via code reading: set_platform_info (the mise lock path) and merge_tool_entries (the mise install/mise use lockfile-update path) both key/match lockfile entries by exact (version, options) equality. When java's shorthand_vendor gets attached to a version that previously round-tripped with no options, the freshly-resolved entry no longer matches the on-disk (version, {}) entry — set_platform_info pushes a new sibling instead of updating in place, and merge_tool_entries silently drops the old entry from the merge result entirely.

The fix adopts an existing same-version entry with empty options into the newly-optioned one (merging platforms, updating options in place) instead of creating/losing a sibling, scoped narrowly to that empty→non-empty transition — other option differences (e.g. a real release_type change) still produce separate entries, since those describe genuinely different artifacts. Includes 3 regression tests covering both write paths plus the monorepo preserve pass.

@risu729 flagging this so we don't duplicate work — happy to adjust the approach if you were already looking at a different angle.

[zeitlinger]

Thanks a lot - I didn't have any approach in mind so far.

[risu729]

Thanks for fixing it @JamBalaya56562!
I now had a look, and I think the PR is a good workaround. The root cause seems more complicated, but I guess we can't fix it in the short term.
Also, sorry for the regression. I didn't check the lockfile compatibility while the upgrade.

[risu729]

Opened follow-up PR #10918: #10918

#10710 fixed the empty-options to non-empty-options migration. This follow-up covers the remaining case where an existing non-empty option map is a strict subset of newly resolved options, such as Java EA shorthand moving from release_type = "ea" to release_type = "ea" plus shorthand_vendor = "openjdk". It preserves platform data only when there is one compatible superset and shared option values are unchanged.

This comment was generated by an AI coding assistant.