bazel aquery returns same ActionKey even when file contents have changed

[indragiek]

Description of the problem / feature request:

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.

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

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.

What operating system are you running Bazel on?

macOS 10.15.5

What's the output of bazel info release?

release 3.3.1

Have you found anything relevant by searching the web?

• I found the --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 change
• Doing a bazel build or bazel shutdown prior to re-checking the output of bazel aquery does not help

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

Minimal repro project: action_key_repro.zip

[meisterT]

cc @joeleba

[sdtwigg]

The documentation of that use of the term ActionKey is referred to here:

bazel/src/main/java/com/google/devtools/build/lib/actions/ActionExecutionMetadata.java

Line 47 in a9c71b4

/**

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.)

[joeleba]

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.

[indragiek]

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?

[burdiyan]

Just got hit by this. This was a surprised behavior for something called an ActionKey. Is there a way to obtain the actual RemoteCache::ActionKey for a target by using some of the Bazel's querying facilities?

[benjaminp]

No—the feature request for it is #7962.