Trouble with .d files in Bazel 7

Hi,

We are currently in the process of upgrading from Bazel 6 to 7.4.1 but I've run into an issue with .d files that I haven't been able to solve. Bazel 7 made --experimental_inmemory_dotd_files the default, but this breaks in combination with remote downloads (https://github.com/bazelbuild/bazel/issues/22387#issuecomment-2854925806). Disabling it (which was the default in Bazel 6) fixes this issue, but now the build is failing with this kind of error:

(15:33:21) ERROR: /home/stefan.zeiger/.cache/bazel/_bazel_stefan.zeiger/d00c01fef92223f67b669d97f4888ed0/external/com_google_googleapis/google/rpc/BUILD.bazel:24:14: Compiling external/com_google_googleapis/google/rpc/code.pb.cc failed: error while parsing .d file: /home/stefan.zeiger/.cache/bazel/_bazel_stefan.zeiger/d00c01fef92223f67b669d97f4888ed0/execroot/runtime/bazel-out/k8-fastbuild/bin/external/com_google_googleapis/google/rpc/_objs/code_proto/code.pb.pic.d (No such file or directory)

The file does not exist, and there is no .asm file in its place, either.

This only happens when a target is built as a dependency. Building the failing target directly as a top-level output works correctly, and then a subsequent build that uses it as a dependency will also succeed. Similarly, building with --experimental_inmemory_dotd_files (if it succeeds) creates the file and a subsequent build with --noexperimental_inmemory_dotd_files is able to use it.

Both issues look like obvious bugs but the first one is an already closed ticket (which apparently didn't fix it) and I wasn't able to find any useful information on the second one. The only reference I could find was that the "dependency_file" feature needs to be enabled for the .d files to be generated, but it makes no difference if I enable it or not.

Does anyone have suggestions for a workaround? Based on the comments in the source it doesn't look like this .d scanning can be disabled for C++.

2. Provide a bit more information on the Remote Cache/RBE system you are using.
3. Provide a minimal reproduction repo.

Cheers,
Son Luong.

Thanks, 

--remote_download_all fixes the problem. I was also able to test 7.6.1 in the meantime and it makes no difference, I still get the same errors without --remote_download_all. I ran some benchmarks and didn't see any significant effect on build performance with or without the remote cache. We're using https://github.com/buchgr/bazel-remote as the remote cache. RBE was not enabled for these builds.