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

lqiu96 · 2026-07-23T22:37:42Z

Thanks! I think the changes are looking good. I've added another round of comments and smaller changes for readability.

One question that probably depends on plans regarding stability of request tags: When do we feel comfortable marking it from @BetaApi to GA? I'm thinking that the methods in the Datastore interface that do not have DatastoreExecutionOptions probably should be marked with @ObsoleteApi so users know to migrate over to the stable public surface. But everything is marked with @BetaApi which may not be something we should have users migrate to.

Perhaps it may be better to mark the requestTag getters/ settings with @BetaApi instead? Since 2/3 of DatastoreExecutionOptions (Explain and Read Options are stable, just the request tags is new)

rahulmane-goog · 2026-07-24T11:17:09Z

Thanks! I think the changes are looking good. I've added another round of comments and smaller changes for readability.

One question that probably depends on plans regarding stability of request tags: When do we feel comfortable marking it from @BetaApi to GA? I'm thinking that the methods in the Datastore interface that do not have DatastoreExecutionOptions probably should be marked with @ObsoleteApi so users know to migrate over to the stable public surface. But everything is marked with @BetaApi which may not be something we should have users migrate to.

Perhaps it may be better to mark the requestTag getters/ settings with @BetaApi instead? Since 2/3 of DatastoreExecutionOptions (Explain and Read Options are stable, just the request tags is new)

We are planning to do a public preview of supporting request tags , the backend changes are already enabled. Should I create a separate bug for doing what you suggested?

lqiu96 · 2026-07-24T15:55:44Z

Should I create a separate bug for doing what you suggested?

Sure, I think that also works. We don't need to encourage people to use the new variants until they stabilize. In that case, I think it may also be worthwhile to add @BetaApi on getRequestOptions and getRequestTags methods

lqiu96 · 2026-07-24T16:09:50Z

Changes generally LGTM, added some small comments. Please also let @jinseopkim0 another chance to review and I'll be fine to approve

… in DatastoreImpl

lqiu96 · 2026-07-31T15:55:55Z

+        toReadOptionsPb(executionOptions.getReadOptions().toArray(new ReadOption[0])),
+        query,
+        explainOptions != null ? explainOptions.toPb() : null,
+        executionOptions.getRequestOptions() != null


IIUC, we should have enforced that requestOptions cannot be null. There is a default value which should have a default instance.

lqiu96 · 2026-07-31T15:56:02Z

+              ? executionOptions.getExplainOptions().toPb()
+              : null;
+      RequestOptions requestOptions =
+          executionOptions.getRequestOptions() != null


lqiu96

LGTM, thanks for the changes and working with us on this!

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