Prunable headers are missing from blaze aquery output

[Fil-Den]

Description of the bug:

One time, I wanted to find the dependency chain using a query, but couldn't do it because the aquery didn't show the headers at the action inputs.

Probably, it's a consequence of the Bazel logic for parsing the /showincludes results or dotd files.

Example with embedded Bazel target.
How does the target actually look? https://github.com/bazelbuild/bazel/blob/b03e4c5e4df4728b943945370141c047b9d98039/tools/cpp/runfiles/BUILD#L51C1-L56C2

$ ../../bazel/bazel cquery 'somepath(@bazel_tools//tools/cpp/runfiles, @bazel_tools//tools/cpp/runfiles:runfiles.h)'
INFO: Analyzed 2 targets (0 packages loaded, 0 targets configured).
INFO: Found 2 targets...                                                                                                                                                                                                                                                                                             
@bazel_tools//tools/cpp/runfiles:runfiles (5c86453)                                                                                                                                                                                                                                                                  
@bazel_tools//tools/cpp/runfiles:runfiles.h (null)
INFO: Elapsed time: 0.306s, Critical Path: 0.00s                                                                                                                                                                                                                                                                     
INFO: 0 processes.                                                                                                                                                                                                                                                                                                   
INFO: Build completed successfully, 0 total actions
                                                                                                                                                                                                                                                                  
$ ../../bazel/bazel aquery 'mnemonic("CppCompile", @bazel_tools//tools/cpp/runfiles)' | grep "Inputs"
Computing main repo mapping: 
Loading:
Loading: 0 packages loaded
Analyzing: target @@bazel_tools//tools/cpp/runfiles:runfiles (0 packages loaded, 0 targets configured)
INFO: Analyzed target @@bazel_tools//tools/cpp/runfiles:runfiles (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
  Inputs: [bazel-out/k8-fastbuild/bin/external/bazel_tools/tools/cpp/runfiles/runfiles.cppmap, external/bazel_tools/tools/cpp/runfiles/runfiles.cc, external/bazel_tools~cc_configure_extension~local_config_cc/builtin_include_directory_paths, external/bazel_tools~cc_configure_extension~local_config_cc/cc_wrapper.sh, external/bazel_tools~cc_configure_extension~local_config_cc/module.modulemap]
INFO: Elapsed time: 0.519s, Critical Path: 0.00s
INFO: 0 processes.
INFO: Build completed successfully, 0 total actions

Which category does this issue belong to?

No response

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Executing queries in any Bazel repository from the bug description.

Which operating system are you running Bazel on?

Windows, Linux

What is the output of bazel info release?

release 7.2.1

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse HEAD ?

No response

If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.

No response

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

No response

[tjgq]

Use the --include_scheduling_dependencies option to bazel aquery. FWIW, my opinion is that we should just change aquery to include the header files in the inputs; having that gated by a separate option is too confusing.

[Fil-Den]

@tjgq, thanks, I found that the flag is only available in the pre-release Bazel 8 version, and the current Bazel 7 doesn't support it. But I'm glad to hear you're aware of this problem.

[tjgq]

To expand a bit on the issue: due to how Bazel works internally (the action inputs are mutated in place after input discovery), all headers are missing if aquery is run before action execution, and headers that survive pruning are present if aquery is run after action execution. (For Bazel, all headers survive pruning since include scanning is a Blaze-only feature; I'm only including this sentence for additional context.)

In a related note, I've recently discovered that aquery will also omit pruned inputs (i.e., inputs reported in a unused_inputs_list for a Starlark action or the equivalent mechanism for native C++ and Java actions) when run after execution, including when the action is loaded from the persistent action cache. In this case there's no way to force aquery to report them, as they're (afaict) completely gone from Bazel's internal representation of the action.

Keeping this untriaged so we discuss it at the next subteam meeting and decide what to do about it.

[fmeum]

@tjgq A nitpick to prevent potential confusion: I think that Bazel's Java actions do not use input pruning (they just create spawns with fewer inputs).

[tjgq]

@tjgq A nitpick to prevent potential confusion: I think that Bazel's Java actions do not use input pruning (they just create spawns with fewer inputs).

Yes, you are correct :)