Correction: the premise of this issue was wrong
I opened this claiming bazel (cloud-functions) rebuilds from scratch as a standing property, based on it getting 5.5% cache hits on #777 while instance-cluster-management got 67% on the same run and commit. I inferred the difference was intrinsic to cloud-functions.
It is not. The same job on #974, a pull request that does not touch MODULE.bazel.lock:
#777 (lock repin): 3073 processes: 168 remote cache hit, 1010 internal, 1916 processwrapper-sandbox
#974 (no repin): 3073 processes: 2063 remote cache hit, 1010 internal, 21 processwrapper-sandbox
67% hits and 21 locally executed actions, the same healthy profile ICMS had. Stamping actions fell from 74 to 19.
So cloud-functions caches normally. It rebuilt on #777 because the crate_universe repin genuinely invalidated the inputs to its dependency-manifest stamping. My original explanation was correct, and the "correction" I made to it was the error: ICMS was cached and cloud-functions was not on that run, but the cause was the repin reaching one row's graph and not the other's, not a defect in cloud-functions.
What is actually left
A narrow, low-value observation: cloud-functions stamps the manifest of each third-party dependency (Stamping the manifest of @nv_third_party_deps//:...) and ICMS does not, so a lock repin costs cloud-functions more rebuilding than it costs ICMS.
That cost is now mostly unreachable. #974 stops a Rust-only lock repin from scheduling the Java rows at all, which is the case that produced every measurement here. A repin that genuinely affects Java will still schedule them and still pay the stamping cost, but that is a correct rebuild, not waste.
Closing. The remaining asymmetry is not worth chasing on its own, and leaving this open with a wrong premise would send someone after a problem that is not there. If Java rows are seen rebuilding on a commit that does not repin the lock, that is a real signal and worth a fresh issue with the INFO: N processes line attached.
Correction: the premise of this issue was wrong
I opened this claiming
bazel (cloud-functions)rebuilds from scratch as a standing property, based on it getting 5.5% cache hits on #777 whileinstance-cluster-managementgot 67% on the same run and commit. I inferred the difference was intrinsic to cloud-functions.It is not. The same job on #974, a pull request that does not touch
MODULE.bazel.lock:67% hits and 21 locally executed actions, the same healthy profile ICMS had.
Stampingactions fell from 74 to 19.So cloud-functions caches normally. It rebuilt on #777 because the crate_universe repin genuinely invalidated the inputs to its dependency-manifest stamping. My original explanation was correct, and the "correction" I made to it was the error: ICMS was cached and cloud-functions was not on that run, but the cause was the repin reaching one row's graph and not the other's, not a defect in cloud-functions.
What is actually left
A narrow, low-value observation: cloud-functions stamps the manifest of each third-party dependency (
Stamping the manifest of @nv_third_party_deps//:...) and ICMS does not, so a lock repin costs cloud-functions more rebuilding than it costs ICMS.That cost is now mostly unreachable. #974 stops a Rust-only lock repin from scheduling the Java rows at all, which is the case that produced every measurement here. A repin that genuinely affects Java will still schedule them and still pay the stamping cost, but that is a correct rebuild, not waste.
Closing. The remaining asymmetry is not worth chasing on its own, and leaving this open with a wrong premise would send someone after a problem that is not there. If Java rows are seen rebuilding on a commit that does not repin the lock, that is a real signal and worth a fresh issue with the
INFO: N processesline attached.