Description of the bug:
In some situations (see reproduction example below) bazel 7.7.1 (and also other bazel-7 versions) bazel mod gives inconsistent answers
bazel mod dump_repo_mapping '' shows a repository as visible from the main repository, whereas
bazel mod show_repo claims that this repository does not exist.
I have not found anything in the documentation that such a mismatch would be expected. It seems that this behavior occurs when a WORKSPACE file depends on a module pulled in by the MODULE.bazel file. While this seems contrived, the reproduction case is based on a real-world example.
Which category does this issue belong to?
External Dependency
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Using bazelisk
~>cd $(mktemp -d)
/tmp/tmp.f8XQb62vAj>echo 7.7.1 > .bazelversion
/tmp/tmp.f8XQb62vAj>echo 'bazel_dep(name = "aspect_rules_lint", version = "1.0.0-rc10")' > MODULE.bazel
/tmp/tmp.f8XQb62vAj>cat > WORKSPACE <<EOF
load(
"@aspect_rules_lint//format:repositories.bzl",
"fetch_ktfmt",
)
fetch_ktfmt()
EOF
/tmp/tmp.f8XQb62vAj>touch BUILD
/tmp/tmp.f8XQb62vAj>bazel mod dump_repo_mapping '' | jq .ktfmt
Starting local Bazel server and connecting to it...
(09:51:12) INFO: Invocation ID: bf188608-e00e-4f3c-8795-6d6ce960e354
(09:51:13) INFO: Current date is 2026-02-10
(09:51:13) no actions running
(09:51:14) no actions running
(09:51:15) no actions running
(09:51:16) no actions running
"ktfmt"
/tmp/tmp.f8XQb62vAj>bazel mod show_repo ktfmt
(09:51:37) INFO: Invocation ID: 3741266f-2bf0-4ca8-bb86-20cbe0b0ff2b
(09:51:37) INFO: Current date is 2026-02-10
(09:51:37) ERROR: In repo argument ktfmt: Module ktfmt does not exist in the dependency graph. (Note that unused modules cannot be used here). Type 'bazel help mod' for syntax and help.
/tmp/tmp.f8XQb62vAj>bazel mod show_repo @ktfmt
(09:51:54) INFO: Invocation ID: 3646e11b-e1e0-4fe2-80c3-6536c0728a30
(09:51:54) INFO: Current date is 2026-02-10
(09:51:54) ERROR: In repo argument @ktfmt: No repo visible as ktfmt from @main repository (Note that unused modules cannot be used here). Type 'bazel help mod' for syntax and help.
/tmp/tmp.f8XQb62vAj>bazel mod show_repo @@ktfmt
(09:52:04) INFO: Invocation ID: 9d3d98a6-008e-4e61-aaff-4aa7d262b21e
(09:52:04) INFO: Current date is 2026-02-10
(09:52:04) ERROR: In repo argument @@ktfmt: no such repo. Type 'bazel help mod' for syntax and help.
/tmp/tmp.f8XQb62vAj>
Which operating system are you running Bazel on?
Ubuntu 24.04.3
What is the output of bazel info release?
release 7.7.1
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 ?
If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.
No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
No response
Description of the bug:
In some situations (see reproduction example below) bazel 7.7.1 (and also other bazel-7 versions)
bazel modgives inconsistent answersbazel mod dump_repo_mapping ''shows a repository as visible from the main repository, whereasbazel mod show_repoclaims that this repository does not exist.I have not found anything in the documentation that such a mismatch would be expected. It seems that this behavior occurs when a
WORKSPACEfile depends on a module pulled in by theMODULE.bazelfile. While this seems contrived, the reproduction case is based on a real-world example.Which category does this issue belong to?
External Dependency
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Using bazelisk
Which operating system are you running Bazel on?
Ubuntu 24.04.3
What is the output of
bazel info release?release 7.7.1
If
bazel info releasereturnsdevelopment versionor(@non-git), tell us how you built Bazel.No response
What's the output of
git remote get-url origin; git rev-parse HEAD?If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.
No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
No response