feat: refactor timeout

[NguyenHoangSon96]

Closes #

Proposed Changes

• Query and write timeout will not be passed directly to the transport. It will be passed to the query or write functions.
• Users can pass a timeout directly to the query and write APIs now, and they will have the highest priority.

Checklist

• CHANGELOG.md updated
• Rebased/mergeable
• A test has been added if appropriate
• Tests pass
• Commit messages are conventional
• Sign CLA (if not already signed)

[karel-rehor]

This looks good for passing timeout arguments to underlying APIs. Maybe I've missed something, but I don't see client properties like writeTimeout and queryTimeout

To synchronize changes with other libraries, in addition to sending a timeout value as a function argument, we also need to set a default writeTimeout and queryTimeout value when instantiating the client or its configuration. This especially needs to be used on the query side (https://grpc.io/docs/guides/deadlines/#deadlines-on-the-client and https://grpc.io/blog/deadlines/).

Having a client property that gets reused with every call will be much more convenient for users, than having to set the timeout with every call.

[vlastahajek]

Why flood the write and query API with the timeout parameter?
Is it really necessary to change the timeout for each call?

queryTimeout is already part of the options and is used correctly.
We could add just writeTimeout to properly differentiate values.

[NguyenHoangSon96]

Why flood the write and query API with the timeout parameter? Is it really necessary to change the timeout for each call?

queryTimeout is already part of the options and is used correctly. We could add just writeTimeout to properly differentiate values.

• The queryTimeout and writeTimeout were "flushed" for each call because maybe there are some cases where users want to override the timeout for only a specific query; It also makes the APIs consistent with other libraries. Now users can set a one-time timeout.

[vlastahajek]

The queryTimeout and writeTimeout were "flushed" for each call because maybe there are some cases where users want to override the timeout for only a specific query;

Maybe? We should be pretty sure about use-cases before changing API.

It also makes the APIs consistent with other libraries. Now users can set a one-time timeout.

What other libraries have the timeout parameter in the insert and query-like functions? I've checked Mongo and Postgresql and haven't found that.
Of course, there are already WriteOptions and QueryOptions parts for write and query functions.
If needed, the timeout parameter should be part of those, instead of adding a new parameter.

[NguyenHoangSon96]

The queryTimeout and writeTimeout were "flushed" for each call because maybe there are some cases where users want to override the timeout for only a specific query;

Maybe? We should be pretty sure about use-cases before changing API.

It also makes the APIs consistent with other libraries. Now users can set a one-time timeout.

What other libraries have the timeout parameter in the insert and query-like functions? I've checked Mongo and Postgresql and haven't found that. Of course, there are already WriteOptions and QueryOptions parts for write and query functions. If needed, the timeout parameter should be part of those, instead of adding a new parameter.

I'm not talking about other libraries like Mongo or Posgrest, but our client libs like influxdb3-java, influxdb3-python, influxdb3-go,....

[vlastahajek]

Neither of the other InfuxDB 3 client libraries has a timeout as a parameter of the write or query function.

[NguyenHoangSon96]

Neither of the other InfuxDB 3 client libraries has a timeout as a parameter of the write or query function.

Hi @vlastahajek
Ok, so there are some misunderstandings between me and Karel regarding how we should pass the timeout to functions.
I have changed the code to use QueryOptions and WriteOptions.
Please check again.

[karel-rehor]

@NguyenHoangSon96, @vlastahajek
The main point that arose from working on the Tarana EAR was that on the query side the gRPC error DeadlineExceeded should be triggered and captured, when the user defines a timeout directly or as a gRPC deadline option. So timeout should be an optional argument in a method call or an optional parameter in the configuration. Additionally the GRPC developers recommend setting deadlines (i.e. timeouts):

By default, gRPC does not set a deadline which means it is possible for a client to end up waiting for a response effectively forever. To avoid this you should always explicitly set a realistic deadline in your clients.

When working on the python client I added timeout as a handled known kwarg on query methods. The argument _request_timeout was already being used for write methods. I considered it a potentially useful feature to be able to override the timeout set in the client configuration with an optional argument in the call method. Note that in other clients, like the Java client, the deadline can be set as part of the gRPC options call argument. But this is a bit hidden for some users.

[karel-rehor]

I have some problems with some of the deprecated fields. queryTimeout is already an important value passed to the GrpcTransport, and likely should not be removed. It is also self descriptive. The option timeout can also simply be made more specific by creating a writeTimeout field which fulfills the same function.

[vlastahajek]

Also, current tests don't validate correct timeout propagation

[NguyenHoangSon96]

Hi @karel-rehor
Can you approve these changes? I was blocked.