Description of the bug:

This is similar to #20721, but 1) about repository rules rather than module extensions and 2) not a regression in 7.0.0.

A repository rule isn't refetched when its repo mapping changes, which can result in Label(...) calls made in the implementation function to return stale results when canonical repo names change, e.g. during bazel_dep version bumps.

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.

# MODULE.bazel
bazel_dep(name = "rules_go", version = "0.40.0")

ext = use_extension("//:ext.bzl", "ext")
ext.tag(label_str = "@rules_go//go")
use_repo(ext, "repo")

# BUILD
load("@repo//:defs.bzl", "LABEL")
print(LABEL)

# ext.bzl
def _repo_impl(ctx):
    ctx.file("WORKSPACE")
    ctx.file("BUILD")
    ctx.file("defs.bzl", "LABEL = Label({})".format(repr(str(Label(ctx.attr.label_str)))))

_repo = repository_rule(
    implementation=_repo_impl,
    attrs={"label_str": attr.string(mandatory=True)},
)

_tag = tag_class(
    attrs={"label_str": attr.string(mandatory=True)},
)

def _ext_impl(ctx):
    for module in ctx.modules:
        for tag in module.tags.tag:
            _repo(name = "repo", label_str = tag.label_str)

ext = module_extension(
    implementation=_ext_impl,
    tag_classes={"tag": _tag},
)

$ bazel build //... --lockfile_mode=off
DEBUG: /home/fhenneke/tmp/repo-mapping-lock/BUILD:2:6: @@rules_go~0.40.0//go:go
$ buildozer 'set version 0.41.0' MODULE.bazel:rules_go
$ bazel build //... --lockfile_mode=off
<no output since the old warning has already been omitted and hasn't changed>
$ bazel shutdown
$ bazel build //... --lockfile_mode=off
DEBUG: /home/fhenneke/tmp/repo-mapping-lock/BUILD:2:6: @@rules_go~0.40.0//go:go

Which operating system are you running Bazel on?

No response

What is the output of bazel info release?

7.0.0 and HEAD

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 master; 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?

No response

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

No response