When running bazel aquery for a target, the actions that take source files as inputs show an ActionKey that does not change even when the contents of one or more input source files has changed. I would expect the ActionKey to be a different hash when the contents have changed.
This seems to me like either user error on my part, or a bug with aquery, because I have not seen this result in a stale build where changes don't get picked up.
I have a minimal repro project here:
action_key_repro.zip
Running bazel aquery 'deps(//:foo)' --nohost_deps --notool_deps --noimplicit_deps gives me the output with the following for the "Compiling lib/print.cpp" action:
action 'Compiling lib/print.cpp'
Mnemonic: CppCompile
Target: //:lib
Configuration: darwin-fastbuild
ActionKey: 544ad9739062047cec3cafbf7fc5e0c3e865c2087f427c38c8b8d9f7aec63c5a
Inputs: [bazel-out/darwin-fastbuild/internal/_middlemen/_S_S_Clib-BazelCppSemantics_build_arch_darwin-fastbuild, bazel-out/host/internal/_middlemen/external_Slocal_Uconfig_Ucc_Cosx_Utools_Udarwin_Ux86_U64, external/bazel_tools/tools/cpp/grep-includes.sh, lib/print.cpp]
Outputs: [bazel-out/darwin-fastbuild/bin/_objs/lib/print.d, bazel-out/darwin-fastbuild/bin/_objs/lib/print.o]
ExecutionInfo: {requires-darwin: '', supports-xcode-requirements-set: ''}
Command Line: (exec external/local_config_cc/wrapped_clang \
...
If I then modify lib/print.cpp by changing the "hello world" string to something else and save it, re-running bazel aquery as described above gives me the exact same output, with the same ActionKey.
macOS 10.15.5
bazel info release?release 3.3.1
--check_up_to_date option -- bazel build --check_up_to_date //:foo correctly reports that it is out of date after I change lib/print.cpp, so this works as expected even when the ActionKey doesn't changebazel build or bazel shutdown prior to re-checking the output of bazel aquery does not helpMinimal repro project: action_key_repro.zip
cc @joeleba
The documentation of that use of the term ActionKey is referred to here: https://github.com/bazelbuild/bazel/blob/a9c71b4c8a6d8b998c950c35c1e0a697a0d68ffa/src/main/java/com/google/devtools/build/lib/actions/ActionExecutionMetadata.java#L47
Roughly, that checksum encapsulates all the information about the actual command to be run by that action but specifically does not incorporate the contents of the input files involved in the action. (Other parts of the action caching mechanism will verify those details).
Thus, this is technically working as intended. I don't think aquery has to actually execute actions but incorporating the contents into that checksum would require this. (As well as have potential performance impact.)
Stephen has answered the question. But this shows that we need to update aquery's documentation to be explicit about what this ActionKey attribute covers.
Thank you for the clarification! Is there a way to get what I'm looking for here -- a hash that accounts for the contents of the input files?