Bazel Remote Cache Serves Stale Artifacts After External Repository Update

Problem Overview

Bazel’s remote cache uses content‑addressable storage keyed by the checksum of downloaded artifacts. When the definition of an external repository (e.g., a git_repository or http_archive) is updated to point at a new commit or URL, Bazel may still reuse a cached artifact if the checksum matches an older version. This can lead to a build that silently consumes stale outputs.

Key Constraints

• The cache key is derived solely from the artifact’s SHA‑256; the repository definition is not part of the key.
• Bazel verifies the checksum against the expected value but does not automatically purge or re‑validate entries when the repository reference changes.
• Documentation does not explicitly state whether a repository change should trigger cache invalidation.

Unresolved Questions

1. Does Bazel re‑download a remote artifact whenever its external repository definition changes, or does it rely solely on checksum matches?
2. Is there a configuration option to force Bazel to re‑validate or purge remote cache entries when a repository definition is updated?
3. What is the recommended workflow to ensure builds do not consume stale artifacts after repository updates?