-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: resolve the issue where rpc timeout of 0 is used when timeout expires #776
Conversation
@@ -102,8 +102,7 @@ def __call__(self, func): | |||
def func_with_timeout(*args, **kwargs): | |||
"""Wrapped function that adds timeout.""" | |||
|
|||
remaining_timeout = self._timeout | |||
if remaining_timeout is not None: | |||
if self._timeout is not None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this self._timeout
is meant to be treated as the total timeout and not a timeout for each retry.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is some clean up that needs to happen as part of a longer term fix (Googlers see b/388247478) but for now I'd recommend to keep the definitions unchanged.
# it is still possible for the `deadline` argument in | ||
# `google.api_core.retry.Retry` to be larger than the `timeout`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does not explain how the deadline
value enters here since there's no deadline
in this function. It's confusing. Please clarify.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The deadline enters via wrap_method
linked below, and is used in the calculation for an overall timeout. The fact that there is a separate deadline that can be confirmed is unexpected behavior which will be addressed in a follow up PR.
def wrap_method( |
if remaining_timeout < 1: | ||
remaining_timeout = self._timeout |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand this. This seems to be saying that if the next server-RPC timeout is ~0, we should reset it to be the GAPIC-surface level timeout, which seems wrong. I assume we're checking the GAPIC-surface level timeout elsewhere? Where?
If we are indeed checking it elsewhere, clarify that here, and explain how the scenario leading up to this situation means it should be reset to self._timeout
instead of, say, 5.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right @vchudnov-g , there is existing incorrect behavior and this simply avoids the specific failure of sending requests with an rpc timeout of 0, which fail immediately. More clarity is needed to document the current incorrect behavior and the workaround in this PR, as well as the recommended long term fix. As per offline discussion, we'll merge this as is and follow up with another PR to update the comments to provide more clarity.
In PR #462, the deadline argument of google.api_core.retry.Retry was refactored and marked as deprecated. Although the comment below mentions that the
deadline
argument would override thetimeout
, this is not the behavior that we see when thedeadline
argument ofdefault_retry
is set as part of the wrapped method as is the case in this line, similar to the bug report in #654.python-api-core/google/api_core/retry/retry_unary.py
Lines 194 to 200 in b1fae31
We actually have 2 separate values
deadline
andtimeout
which behave in a different manner. Thedeadline
argument ofdefault_retry
is an overall invocation timeout, whiletimeout
is therpc timeout
. The client will send requests (respecting the configured backoff) during the specified timeout allowed. Once the timeout is up, therpc timeout
ends up being 0, but the requests keep going out because thedeadline
hasn't expired.A simple fix is to have a reasonableness check on the
rpc timeout
to avoid sending requests withrpc timeout
of 0.A longer term fix is being considered where we have separate timeouts for
overall timeout
andrpc timeout
. Currently, we just have a singletimeout
defined in pubsub_grpc_service_config.json does not provide flexibility to configure both anoverall timeout
orrpc timeout
.Initial testing shows that this should fix #654
Output of test log. Previously I would see
gRPC timeout:0 seconds
as reported in #654Fixes #654
Fixes b/387530669