You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Feature Request: Add Capability to Override Base Timeout for Specific API
I would like to propose a feature that allows us to override the base timeout for a specific API. This would be beneficial in scenarios where certain APIs are expected to take more time, eliminating the need to adjust the timeout for the entire gRPC client.
Proposal:
A possible implementation could involve exposing a method to add a CallOption. We can then adjust timeout.UnaryClientInterceptor to first iterate over the options. If it identifies a specific CallOption for timeout, it would set the context's deadline equal to what's specified in the CallOption, rather than using the global timeout set for the Server.
This feature would mainly enhance the client side experience by offering more flexibility and control over API timeouts.
Looking forward to hearing your thoughts on this proposal.
The text was updated successfully, but these errors were encountered:
This is already possible today with gRPC CallOptions, no? If you need per-RPC timeouts, don't use the interceptor that sets it the same for all of them, or use it to set a ceiling and use more specific timeouts for specific calls. I'm very weary of introducing more options to the existing interceptors as it's trivial for users with specific use cases to create their own interceptors and it increases the cognitive load of using the interceptor for new users.
Feature Request: Add Capability to Override Base Timeout for Specific API
I would like to propose a feature that allows us to override the base timeout for a specific API. This would be beneficial in scenarios where certain APIs are expected to take more time, eliminating the need to adjust the timeout for the entire gRPC client.
Proposal:
A possible implementation could involve exposing a method to add a
CallOption
. We can then adjusttimeout.UnaryClientInterceptor
to first iterate over the options. If it identifies a specificCallOption
for timeout, it would set the context's deadline equal to what's specified in the CallOption, rather than using the global timeout set for the Server.This feature would mainly enhance the client side experience by offering more flexibility and control over API timeouts.
Looking forward to hearing your thoughts on this proposal.
The text was updated successfully, but these errors were encountered: