feat(datastore): add support for request tags by rahulmane-goog · Pull Request #13732 · googleapis/google-cloud-java

rahulmane-goog · 2026-07-13T13:26:55Z

This PR introduced sending request tags for different datastore requests. The tags can be passed using 2 mechanisms:

Instance Level tags.
Request Level tags.

RequestOptions is the proto that holds all the instance and request level tags and is a part of all request protos.
DatastoreOptions allows the ability to set the instance level tags using setRequestTags. Any operation executed via this Datastore client automatically includes these global request tags in the outbound RPC request payload.
RequestOptionsHelper an internal utility that combines instance-level tags from DatastoreOptions with any request-level RequestOptions protobuf message before building the wire request.
DatastoreExecutionOptions is a holder object for all different options like ExplainOptions, RequestOptions and ReadOption.
Overloaded versions for taking in the DatastoreExecutionOptions for each of the following operations:
- put
- get
- fetch
- delete
- newTransaction
- commit
- rollback
- allocateId
- reserveIds
- runQuery
- runAggregationQuery
Each of these overloaded versions copy the request tags into the request protos.

gemini-code-assist

Code Review

This pull request introduces support for passing and merging RequestOptions (such as request tags) in Datastore queries and aggregation queries, allowing both instance-level and request-level tags to be propagated. The feedback highlights a critical issue where instance-level tags are ignored when query-level RequestOptions are not explicitly provided in QueryResultsImpl and AggregationQueryRequestProtoPreparer. Additionally, the reviewer suggests simplifying the varargs withRequestTags overload in Datastore by delegating to the List version, and adding a test case to verify that instance-level tags are correctly populated and sent with queries.

rahulmane-goog

Please review

jinseopkim0 · 2026-07-13T20:21:26Z

ci / lint is failing. Could you please take a look?

rahulmane-goog · 2026-07-14T06:26:15Z

ci / lint is failing. Could you please take a look?

Fixed

…uplication

…ution options

lqiu96 · 2026-07-16T15:36:25Z

+   */
+  @BetaApi
+  Transaction newTransaction(
+      TransactionOptions options, DatastoreExecutionOptions executionOptions);


Thanks for being open for using DatastoreExecutionOptions. IIRC, the original commits only needed RequestOptions for run and runAggregation, right?

Do all the other RPCs also need RequestOptions functionality?

lqiu96 · 2026-07-16T15:38:47Z

+     * @param requestTags the list of request tags to set
+     * @return the builder object
+     */
+    public Builder setRequestTags(ImmutableList<String> requestTags) {


nit: Can the parameter be of List to be as general as possible?

We can copy the contents over to an immutablelist ourselves to ensure they don't change.

lqiu96 · 2026-07-16T15:42:31Z

+        ExplainOptions explainOptions,
+        List<ReadOption> readOptions,
+        RequestOptions requestOptions) {


nit: We can probably replace these three params with DatastoreExecutionOptions and assign the vars from there

this.explainOptions = datastoreExecutionOptions.getExplainOptions()

lqiu96 · 2026-07-16T15:43:40Z

+    public static <Q extends Query<?>> QueryConfig<Q> create(
+        Q query,
+        ExplainOptions explainOptions,
+        List<ReadOption> readOptions,
+        RequestOptions requestOptions) {
+      return QueryConfig.<Q>newBuilder()
+          .setQuery(query)
+          .setExplainOptions(explainOptions)
+          .setReadOptions(readOptions)
+          .setRequestOptions(requestOptions)
+          .build();
+    }


nit: Do we need to expose this variant of create if we have:

createWithExecutionOptions(Q query, DatastoreExecutionOptions executionOptions) {?

Can we just have the call this by building the DatastoreExecutionOptions with the required options?

lqiu96 · 2026-07-16T15:44:20Z

+      public Builder<Q> setReadOptions(List<ReadOption> readOptions) {
+        this.readOptions = readOptions;
+        return this;
+      }
+
+      public Builder<Q> setExplainOptions(ExplainOptions explainOptions) {
+        this.explainOptions = explainOptions;
+        return this;
+      }
+
+      public Builder<Q> setRequestOptions(RequestOptions requestOptions) {
+        this.requestOptions = requestOptions;
+        return this;
+      }


nit: Same here, can the caller just call something like setDatastoreExecutionOptions which has all the required options?

lqiu96 · 2026-07-16T15:45:48Z

+    public Builder setReadOptions(ReadOption... readOptions) {
+      this.readOptions = readOptions != null ? Arrays.asList(readOptions) : Collections.emptyList();
+      return this;
+    }
+
+    public Builder setReadOptions(List<ReadOption> readOptions) {
+      this.readOptions = readOptions != null ? readOptions : Collections.emptyList();
+      return this;
+    }


(I may have asked this earlier, but forgot)

What is the need to expose both the varargs and List options in Datastore? Can we only expose the List<?> option for users to pass in? For existing methods that have varargs, we can just pack it into a list and set it here

rahulmane-goog requested review from a team as code owners July 13, 2026 13:26

gemini-code-assist Bot reviewed Jul 13, 2026

View reviewed changes

rahulmane-goog force-pushed the feat-datastore-request-tags branch from f124116 to aab1fd3 Compare July 13, 2026 13:43

rahulmane-goog commented Jul 13, 2026

View reviewed changes

lqiu96 added the kokoro:force-run Add this label to force Kokoro to re-run the tests. label Jul 13, 2026

yoshi-kokoro removed the kokoro:force-run Add this label to force Kokoro to re-run the tests. label Jul 13, 2026

jinseopkim0 reviewed Jul 13, 2026

View reviewed changes