-
-
Notifications
You must be signed in to change notification settings - Fork 927
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
Add separate transport option for retry loop timeout #1599
Add separate transport option for retry loop timeout #1599
Conversation
I tested that this solves my issue when using Celery. |
Also I'm not sure about the naming of Alternatives I could come up with: |
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.
how does connect_retry_timeouts sound?
d6f12ed
to
e874d06
Compare
Sorry I had missed your comment. I have renamed the setting to Or did you mean |
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.
Maybe connect_retries_timeout then seems ok. but the tests are failing. can you recheck please?
This only applies when using `Connect.default_channel`. Before this change, the retry loop timeout was set equal to TCP connect timeout (`connect_timeout`), meaning when first connection attempt timeouted, no retry would be attempted. Now if a new transport option `connect_total_timeout` is provided, this overrides `connect_timeout` for the retry loop (but not for TCP connect).
e874d06
to
f46918e
Compare
Renamed to
The failures don't seem to be related to my changes. Let's see if it gets resolved with a rebase. |
@auvipy Can you approve the workflows so we can see if the test issue is fixed? |
Fixes #1594. This only applies when using
Connect.default_channel
.Before this change, the retry loop timeout was set equal to TCP connect timeout (
connect_timeout
), meaning when first connection attempt timeouted, no retry would be attempted.Now, if a new transport option
connect_total_timeout
is provided, this overridesconnect_timeout
for the retry loop (but not for TCP connect).