"bazel aquery" returns no action information for java_proto_library

I'm looking to use bazel aquery to explore inputs and outputs for targets, and have found that java_proto_library produces no output.

For a simple example:

proto_library(
    name = "example_proto",
    srcs = ["example.proto"],
)

java_proto_library(
    name = "example_java_proto",
    deps = [":example_proto"],
)

bazel aquery //:example_proto returns the action information as expected, but bazel aquery //:example_java_proto returns only INFO logging:

INFO: Analyzed target //:example_java_proto (0 packages loaded, 15 targets configured).
INFO: Found 1 target...
INFO: Elapsed time: 0.151s
INFO: 0 processes.
INFO: Build completed successfully, 0 total actions

Full example code at https://github.com/theothertomelliott/bazel-issues/tree/java_proto_aquery

Is this a particular quirk of java_proto_library (I've seen issues raised about src jars and other oddities of this rule), a bug, or something I'm missing in the config?

This is because of the implementation details of java_proto_library, and because of how the build graph is built and how the query functions query it.

java_proto_library doesn't actually register any actions itself: JavaProtoLibrary.java. Instead, it run an aspect over all its deps: BazelJavaProtoLibraryRule.java#L49-L52. That aspect is then evaluated on all the proto dependencies of the java_proto_library, and registers the java proto actions with the proto dependencies: JavaProtoAspect.java#L206

So bazel aquery //:example_java_proto is correct in that that target really has no actions. But bazel aquery //:example_proto also doesn't return java proto actions. The first thing that's needed is --include_aspects, so that aquery outputs information from any aspects attached to the targets.

The 2nd thing is the state of the build graph when aquery is run:

<pre>
$ bazel clean
INFO: Starting clean (this may take a while). Consider using --async if the clean takes more than several minutes.

$ <b>bazel aquery //:example_proto --include_aspects</b> 2>/dev/null | grep action
action 'Generating Descriptor Set proto_library //:example_proto'

$ <b>bazel aquery //:example_java_proto --include_aspects</b> 2>/dev/null | grep action

(nothing)

$ <b>bazel aquery //:example_proto --include_aspects</b> 2>/dev/null | grep action
action 'Generating Descriptor Set proto_library //:example_proto'
action 'Generating Java (Immutable) proto_library //:example_proto'
action 'Building libexample_proto-speed.jar (1 source jar)'
action 'Compiling Java headers libexample_proto-speed-hjar.jar (1 source jar)'
</pre>

So when example_proto is first queried, it returns 1 action, then example_java_proto is queried, and it returns nothing, then example_proto is queried again, and it returns 4 actions: the one from before, and some java ones. This is because when example_java_proto is analyzed, the aspect it registers runs and the graph now contains the actions from the aspect.

This is basically by design, because Bazel doesn't look at anything beyond what it's asked to query or build. If there were a cc_proto_library in some package somewhere, Bazel won't know about it until it's asked to load or analyze that package. Aspects can come from anywhere, so in order to get complete information, Bazel would have to load every BUILD file in the repository, which won't scale for large repositories.

The rdeps query function can be used to get everything:

$ bazel clean
INFO: Starting clean (this may take a while). Consider using --async if the clean takes more than several minutes.

$ bazel cquery "rdeps(//:example_proto, ...)"
INFO: Analyzed 3 targets (20 packages loaded, 908 targets configured).
INFO: Found 3 targets...
//:example_proto (45d0b89373a0dfd75ac4b432cf2b12138c1203b34bdec57557dfef52e7a6ed03)
INFO: Elapsed time: 0.408s
INFO: 0 processes.
INFO: Build completed successfully, 0 total actions

$ bazel aquery //:example_proto --include_aspects 2>/dev/null | grep action
action 'Generating Descriptor Set proto_library //:example_proto'
action 'Generating Java (Immutable) proto_library //:example_proto'
action 'Building libexample_proto-speed.jar (1 source jar)'
action 'Compiling Java headers libexample_proto-speed-hjar.jar (1 source jar)'

rdeps(//:example_proto, //...) will find all the reverse dependencies of example_proto, and the //... loads the entire repository. Note that cquery is needed here, rather than query, because query doesn't run the analysis phase, where actions are created, whereas cquery does run the analysis phase.

java rules is a built-in bazel rule, and its implementation is based on aspects,
so if you first run

bazel build --nobuild //:example_java_proto  

and then

bazel aquery '//:example_proto' --include_aspects=true 

you should see an action graph, enriched with java specific actions