bazel-diff does not work with `--experimental_remote_repo_contents_cache`

Summary

bazel-diff generate-hashes silently produces incorrect, environment-dependent hashes when Bazel uses:

--experimental_remote_repo_contents_cache

Bazel can analyze external repositories while leaving source files remote-backed and absent from <output_base>/external/.... bazel-diff hashes source files using ordinary filesystem APIs. When a file is absent, it logs a warning, hashes a missing-file marker, and exits successfully.

This especially affects repositories selected by --fineGrainedHashExternalRepos or --fineGrainedHashExternalReposFile.

Environment

• Bazel 9.2.0
• bazel-diff 46.1.0
• Linux amd64
• Remote execution
• --remote_download_minimal
• Shared --repo_contents_cache

Reproduction

We ran generate-hashes twice from the same commit with identical inputs and target selection. The only meaningful difference was whether the Bazel server used remote repository contents caching.

Cache enabled

Targets:                       200,599
File-not-found warnings:        51,917
SHA-256: 781c88cf245c91c4065f9952ae10df4874a8660442f02900dbbbeef05b1da80c

Example:

[Warning] File <output_base>/external/rules_rs++crate+crates__jiff-0.2.37/src/tz/system/windows/mod.rs not found

Cache disabled

Targets:                       200,599
File-not-found warnings:            85
SHA-256: 7a01196beff9c2333a1d45ff45209817a95a5af8371ea1cdd06d5c5a8d52da50

Comparison

Added/removed target labels: 0
Changed target hashes:       3,884
Metadata equal:              yes

The target graph was identical. Enabling remote repository contents caching caused 51,832 additional missing files and changed 3,884 hashes without a source change. These differences propagate transitively and can produce many false-positive affected targets.

Cause

The source hasher behaves approximately as follows:

if absolute.is_file() {
    hash_file_into(&mut hasher, &absolute)?;
    hasher.update([1]);
} else {
    eprintln!("[Warn] File {} not found", absolute.display());
    hasher.update([0]);
}

Bazel knows about the remote-backed source artifact, but it is not necessarily available through ordinary filesystem APIs.

We verified that bazel fetch --remote_download_all did not materialize a missing source. Making the source itself a top-level build target did:

bazel build --remote_download_all \
  '@@rules_rs++crate+crates__jiff-0.2.37//:src/tz/system/windows/mod.rs'

Start with the source-hashing path used by generate-hashes, focusing on how it handles files absent from <output_base>/external/... when --experimental_remote_repo_contents_cache is enabled. Reproduce with the stated Bazel flags and compare cache-enabled and cache-disabled runs; the fix is done when identical inputs do not produce environment-dependent hashes or false missing-file results.