v49.1.0 misses external leaf changes through a wrapper that is not root-visible

[lev-olkha]

Summary

With bazel-diff v49.1.0, changing a file in an explicitly selected fine-grained external repository does not mark its workspace consumer as impacted when the dependency chain includes an intermediate module that is not directly visible from the root.

Both hash-generation commands succeed with --no-keep_going. The leaf's hash changes, but the consumer's hash does not.

Explicitly including every repository in the wrapper chain restores propagation. I would like to clarify whether that enumeration is required by the intended contract, or whether this is a remaining coverage gap related to #197.

Environment

• bazel-diff v49.1.0, published native macOS ARM64 binary
• Bazel 8.7.0
• Bzlmod with local_path_override
• Unconfigured query mode
• No query exclusions or custom content hashes

I reproduced this locally. The script below was run with an environment-specific addition routing downloads through an internal artifact mirror. The fixture and reproduction commands were unchanged. Module discovery completed successfully, and both snapshots contained identical module-graph metadata.

Dependency structure

//:consumer
  -> @facade//:export
     -> @@middle+//:wrapped
        -> @leaf//:value
           -> @leaf//:value.txt

The root declares facade and leaf. Only facade declares middle, under the apparent name private_wrapper. Therefore, @private_wrapper is valid inside facade, but not from the root.

An independent bazel query 'deps(//:consumer)' confirms the chain above.

Minimal reproduction

Assumes the v49.1.0 native executable is available as bazel-diff, and bazel runs Bazel 8.7.0.

set -euo pipefail

work="$(mktemp -d)"
mkdir -p "$work"/{root,facade,middle,leaf,results}

cat > "$work/root/.bazelversion" <<'EOF'
8.7.0
EOF

cat > "$work/root/MODULE.bazel" <<'EOF'
module(name = "identity_probe")
bazel_dep(name = "facade", version = "1.0")
bazel_dep(name = "leaf", version = "1.0")
local_path_override(module_name = "facade", path = "../facade")
local_path_override(module_name = "middle", path = "../middle")
local_path_override(module_name = "leaf", path = "../leaf")
EOF

cat > "$work/root/BUILD.bazel" <<'EOF'
filegroup(name = "consumer", srcs = ["@facade//:export"])
filegroup(name = "control", srcs = ["control.txt"])
EOF
printf 'unchanged\n' > "$work/root/control.txt"

cat > "$work/facade/MODULE.bazel" <<'EOF'
module(name = "facade", version = "1.0")
bazel_dep(name = "middle", version = "1.0", repo_name = "private_wrapper")
EOF

cat > "$work/facade/BUILD.bazel" <<'EOF'
alias(
    name = "export",
    actual = "@private_wrapper//:wrapped",
    visibility = ["//visibility:public"],
)
EOF

cat > "$work/middle/MODULE.bazel" <<'EOF'
module(name = "middle", version = "1.0")
bazel_dep(name = "leaf", version = "1.0")
EOF

cat > "$work/middle/BUILD.bazel" <<'EOF'
alias(
    name = "wrapped",
    actual = "@leaf//:value",
    visibility = ["//visibility:public"],
)
EOF

cat > "$work/leaf/MODULE.bazel" <<'EOF'
module(name = "leaf", version = "1.0")
EOF

cat > "$work/leaf/BUILD.bazel" <<'EOF'
filegroup(
    name = "value",
    srcs = ["value.txt"],
    visibility = ["//visibility:public"],
)
EOF

printf 'before\n' > "$work/leaf/value.txt"
cd "$work/root"

bazel-diff generate-hashes \
    -w "$PWD" -b bazel \
    --fineGrainedHashExternalRepos=@leaf \
    --no-keep_going --verbose \
    "$work/results/before.json"

printf 'after\n' > "$work/leaf/value.txt"

bazel-diff generate-hashes \
    -w "$PWD" -b bazel \
    --fineGrainedHashExternalRepos=@leaf \
    --no-keep_going --verbose \
    "$work/results/after.json"

bazel-diff get-impacted-targets \
    -w "$PWD" -b bazel \
    --excludeExternalTargets=true \
    -sh "$work/results/before.json" \
    -fh "$work/results/after.json" \
    -o "$work/results/impacted.txt"

cat "$work/results/impacted.txt"

The output files are outside the queried workspace to avoid contaminating subsequent snapshots.

Actual result

Both generate-hashes commands exit successfully. Verbose output includes:

[Warn] Unable to calculate digest for input @facade//:export for rule //:consumer

The impacted targets are:

@leaf//:value
@leaf//:value.txt

//:consumer is missing.

Expected result

I expected //:consumer to be impacted because its transitive input changed, consistent with the wrapped-external-repository behavior covered by #197.

Controls and working configuration

Repeating the comparison with this repository list restores propagation:

--fineGrainedHashExternalRepos=@leaf,@@leaf+,@facade,@@facade+,@@middle+

The canonical names above were obtained from Bazel for this fixture.

Observation	Leaf-only selection	Explicit full chain
No-op snapshots	Identical hashes; no impacts	Identical hashes; no impacts
Leaf content change	Leaf impacted; consumer missed	Leaf and consumer impacted
Unrelated control during leaf change	Unchanged	Unchanged
Change only control.txt	Only control and its source impacted	Only control and its source impacted
Stored module-graph metadata during leaf change	Unchanged	Unchanged

With the full chain selected, the recorded rule dependency edges connect the consumer through both aliases to the leaf. The consumer is not relying on a coarse synthetic repository edge for propagation.

The existing wrapped_external_repo regression fixture declares both its inner and middle modules directly in the root. This reproduction adds a wrapper that is only visible through another module, which appears to expose a case not covered by that fixture.

Possible fix direction

It looks like bazel-diff may need to include the intermediate wrapper targets when following changes from a fine-grained repository to its consumers. In this example, explicitly including the full chain makes the change reach //:consumer.

One possible approach would be to ask Bazel for that dependency chain and use the repository names Bazel returns, rather than expanding module names. That might also avoid pulling unrelated development packages into the query.

I am not sure whether this fits the intended design. If callers are expected to list every intermediate wrapper explicitly, that seems cumbersome and potentially brittle. The list could become stale when transitive dependencies change, leading to missed impacts without an obvious failure. It would be preferable if bazel-diff could discover those connections itself.

The example above could serve as a regression case: the leaf change should reach the consumer, while no-op runs and unrelated targets remain unchanged.

[satori]

We are seeing what appears to be the same failure mode with rules_rs module-extension-generated repositories.

Our environment:

• Bazel 9.2.0
• bazel-diff v48.0.0
• Bzlmod
• rules_rs using crate.from_cargo
• --fineGrainedHashExternalRepos=@crates

The dependency structure is approximately:

//service:binary
  -> @crates//:reqwest
     -> @@rules_rs++crate+crates__reqwest-0.13.5//:reqwest
        -> @crates//:hyper-util-0.1.21
           -> @@rules_rs++crate+crates__hyper-util-0.1.21//:hyper-util

A dependency update changed several transitive crates in Cargo.lock, including:

hyper-util                  0.1.20 -> 0.1.21
encoding_rs                 0.8.41 -> 0.8.42
rustls-platform-verifier    0.7.0  -> 0.7.1
zerocopy                    0.8.57 -> 0.8.58

With only @crates selected for fine-grained hashing, bazel-diff detects the changed versioned targets:

@crates//:hyper-util-0.1.21
@crates//:encoding_rs-0.8.42
@crates//:rustls-platform-verifier-0.7.1
@crates//:zerocopy-0.8.58
...

However, it reports no workspace targets as impacted. The hashes of stable intermediary targets such as these remain unchanged:

@crates//:reqwest
@crates//:reqwest-0.13.5
@crates//:axum
@crates//:kube

Consequently, the workspace consumer hashes remain unchanged as well.

Bazel’s dependency graph contains the expected relationship. For example:

bazel query \
  'rdeps(//... + @crates//..., @crates//:hyper-util-0.1.21)'

returns the affected workspace binaries, tests, and OCI image targets.

As a control, I added the intermediate canonical repository explicitly:

--fineGrainedHashExternalRepos=@crates,@@rules_rs++crate+crates__reqwest-0.13.5

That restored propagation through this dependency path and caused the relevant workspace targets to be reported as impacted.

This seems equivalent to the issue described here: the selected fine-grained repository is separated from workspace consumers by an external repository that is not directly visible from the root. The difference is that our intermediate repositories are generated by a module extension rather than ordinary transitive Bzlmod modules.

The existing automatic expansion through bazel mod graph presumably cannot discover these rules_rs extension-generated repositories. Explicitly enumerating every generated crate repository would also be brittle because the set changes between lockfile revisions.

Although our reproduction currently uses v48.0.0, the behavior reported here on v49.1.0 suggests that upgrading would not address it.