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
{{ message }}
This repository was archived by the owner on Feb 23, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Feb 23, 2026. It is now read-only.
Major refactoring of Timeout logic introduced incompatibility about RPC Timeout #654
I'm using the python-pubsub library and noticed that the timeout behavior is strange. After some investigation, I believe it is due to an incompatibility introduced by #462.
Before #462 was introduced, default_timeout=60.0 was interpreted as default_timeout=ConstantTimeout(60).
This should be intended to set the RPC Timeout, i.e., the timeout for a single RPC call not including retries, to 60 seconds.
However, after the introduction of #462, this line is now interpreted as default_timeout=TimeToDeadlineTimeout(60).
Since TimeToDeadlineTimeout determines the total timeout time across retries rather than determining the RPC Timeout, I don't believe that it can be used as a direct replacement for ConstantTimeout.
The strange behavior I mentioned at the beginning came from this: when the server did not respond in the first 60 seconds, the remaining timeout for RPC call was 0 seconds, and the gRPC client returned a 504 Deadline Exceeded on every retry.
TimeToDeadlineTimeout by itself is useful, but given the original intent, I think it is necessary to specify the RPC Timeout as well as the total timeout.
Finally, in my project, I implemented the following ClampMaxTimeout so that the RPC Timeout can be set while respecting the behavior of TimeToDeadlineTimeout.
Thanks for reporting this issue! I had a quick look and this appears to be an instance where we should at least be clearer, and possibly implement the change we suggest. We'll look into this.
Notes as we investigate:
The code quoted is part of the call to gapic_v1.method.wrap_methodhere.
Activity
vchudnov-g commentedon May 20, 2024
Thanks for reporting this issue! I had a quick look and this appears to be an instance where we should at least be clearer, and possibly implement the change we suggest. We'll look into this.
Notes as we investigate:
gapic_v1.method.wrap_methodhere.google/api_core/gapic_v1/method.py:_GapicCallable.wrap_method.default_timeoutparameter appears to become thetimeoutparameter in_GapicCallable.__init__().parthea commentedon Jan 17, 2025
A fix was released in https://pypi.org/project/google-api-core/2.24.1rc0. I'll keep this issue open until a formal release is published.
parthea commentedon Feb 13, 2025
https://pypi.org/project/google-api-core/2.24.1/