Open askurihin opened 1 year ago
I think adding an automatic delay would be more surprising to most users than having no delay. The library doesn't assume what you're attempting to do is some IO where this is a problem.
I wanted to discuss ways to make this library safer to use, as for me adding default maximum limit of attempt, would be a good option.
Seems like I was not the first, since posting the original issue I discovered stamina that uses tenacity under the hood, but has safe defaults.
I was using the HTTPX library to make async requests to a REST API and would sometimes get 429 Too Many Requests errors. They have a simple retry argument to retry a certain number of times for specific exceptions, but if you need more functionality they recommend Tenacity - https://www.python-httpx.org/advanced/#usage_1
I read through the docs before using Tenacity and I was also surprised that the default was to catch all exceptions and retry forever with no delay between retries. I caught this before using it, but I could see it causing problems if a mistake were made.
I do think it would be good to have a safe default such as wait 1 second and only retry once. If having an automatic delay would be more surprising, maybe just having a lower number of retries like from 1-3 would be safer than retrying forever. Then if someone wants to retry forever have something like:
@retry(stop=False)
Hi 👋🏼 First of all thank you for this library!
Today I got bit by a misconfiguration on my side that could have been prevented if tenacity had more safe defaults. Long story short, I used
tenacity.retry
without any configuration and DDoSed my service. Right nowretry
without any configuration retries function without any delay until it succeeds.Do you think we can introduce more safe defaults, so without any configuration
retry
won't be able to cause such issues?