[bzlmod][6.5.0] Generated lockfile changes when running projects on different platform

[farcop]

Description of the bug:

After lockfile generated with command bazel mod deps --lockfile_mode=update at linux/amd64 platform if I try to build the same code on macos or other different platform, I get error:
ERROR: Analysis of target '//cluster-management-frontend:serve' failed; build aborted: The module extension 'ModuleExtensionId{bzlFileLabel=@rules_go~0.46.0//go:extensions.bzl, extensionName=go_sdk, isolationKey=Optional.empty}'' for platform ModuleExtensionEvalFactors{os=osx, arch=x86_64}' does not exist in the lockfile

As for workaround I have to regenerate lockfile on each build platform I used.
If this is the expected behavior, then please advise how to generate lockfile for multiple platforms at once?

Which category does this issue belong to?

No response

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

I have no sample project to reproduce, but I found the same issue #19154 which was closed.

Which operating system are you running Bazel on?

We use 4 build platforms: [linux, macos] * [amd64, arm64]

What is the output of bazel info release?

release 6.5.0

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse HEAD ?

No response

Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

No response

Have you found anything relevant by searching the web?

#19154

Any other information, logs, or outputs that you want to share?

bazel_dep(name = "rules_go", version = "0.46.0", repo_name = "io_bazel_rules_go")
bazel_dep(name = "gazelle", version = "0.35.0", repo_name = "bazel_gazelle")

[fmeum]

You can't easily generate a lock file for each platform at once as this may require running platform-specific binaries.

The solution that lands in 7.1.0 is to allow extensions such as go_sdk, which are reproducible even without a lockfile entry, to opt out of the lockfile. Once 7.1.0 lands, we will adopt that. Sorry for the inconvenience!

[Wyverald]

I assume your error is caused by using --lockfile_mode=error for the second build; if so, then as @fmeum says, this is indeed working as intended.