Problem

When a Bzlmod extension changes, the committed MODULE.bazel.lock can become stale. In Spruce version 6a991eff148f9c0007fa9560, the following tasks failed during Bazel analysis:

• bazel_run_codeowners
• bazel_run_format
• bazel_run_lint

The failure reported that the implementation of the mongo_apple_toolchain module extension had changed and instructed the user to run:

bazel mod deps --lockfile_mode=update

Current Behavior

• bazel run lint --fix fails before the lint checks run when the lockfile is stale.
• The user must manually regenerate MODULE.bazel.lock before lint can proceed.
• This makes the fix path unable to repair a common repository-state issue and causes multiple CI tasks to fail for the same root cause.

Expected Behavior

When bazel run lint --fix detects this stale-lockfile condition, it should update MODULE.bazel.lock before running the remaining checks. If the update cannot be completed, the command should report an actionable error and preserve the original lockfile. Dry-run mode should not leave lockfile changes behind.

Acceptance Criteria

• bazel run lint --fix repairs a stale Bzlmod extension digest by running an appropriate lockfile update, then continues to the lint and format checks.
• The stale-lockfile scenario is covered by unit tests.
• Failed lockfile updates leave the original lockfile intact and provide a clear remediation message.
• --dry-run does not persist lockfile modifications.
• Normal CI validation continues to detect an out-of-date lockfile rather than silently accepting one.

Related Work

Follow-up to SERVER-116100, which addressed detecting out-of-sync MODULE.bazel.lock files.