Skip to content
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 support for a relay based retry #98

Open
thehesiod opened this issue Oct 11, 2024 · 5 comments
Open

add support for a relay based retry #98

thehesiod opened this issue Oct 11, 2024 · 5 comments
Labels

Comments

@thehesiod
Copy link

thehesiod commented Oct 11, 2024

meaning you do a request, and if after N seconds it doesn't finish, you start another request, and keep repeating up to N requests in parallel. First one that finishes wins, and you cancel the others. With jitter/exp backoff, etc support

@inyutin inyutin added enhancement New feature or request hacktoberfest-accepted and removed enhancement New feature or request hacktoberfest-accepted labels Oct 26, 2024
@inyutin
Copy link
Owner

inyutin commented Oct 26, 2024

Hello @thehesiod !

That's a very interesting proposal. One thing that is missing for me - is why would that be useful? Maybe you can share any additional context, in which environment such behaviour would be nice to have?

In my understanding, usually caller doesn't need to have two requests for the same resource in parallel, because you would create an additional load to the server.

Also I believe that supporting this feature would be a heavy lift for aiohttp_retry, the implementation would need to be completely different from what it is now. I would like to keep package thin. So I would like not to support this as long as this feature is very rare in need.

@thehesiod
Copy link
Author

it is in fact very useful. we use it in several places, like against open search where 1% or less of there is service degradation. what if the service you're calling is degraded. each call you make times out, with a sleep between calls. this makes the server eventually report a 5xx because the backend call failed several times. if instead it's timed and retried correctly, the first call may eventually succeed since it was never cancelled. also if the initial timeout is selected well, 99% of the time it is never retried. of course it needs to be used judiciously

@thehesiod
Copy link
Author

anyhow just a suggestion used in many places. feel free to close as we have our own internal implementation with exponential back off, jitter, etc

@thehesiod
Copy link
Author

actually this reminds me, i saw an impl in aiohappyeyeballs as well, which led me to the idea to expose it in somewhere more appropriate

@inyutin
Copy link
Owner

inyutin commented Oct 27, 2024

I would not do this myself, but if somebody will issue a PR I'm happy to merge

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants