-
Notifications
You must be signed in to change notification settings - Fork 83
Fix bug in handle_rate_limit and take care of proper rounding. #136
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
Conversation
https://discord.com/developers/docs/topics/rate-limits#exceeding-a-rate-limit According the above document, "retry_after" is the number of seconds in float. This should prevent getting temporary bans.
Btw, checks are failing due to dependency installation problem in python 3.11 check.
Thanks for your fix 👍
@lovvskillz Btw any plans for parsing X-RateLimit-Reset and having a global rate limit?
Because this way of handling rate limit might conflict with threads. That is, multiple threads can keep requesting without being aware of the rate limit.
Same with async. When await is called, if another task makes a request, it will create a conflict. How about storing X-RateLimit-Reset globally whenever it is available and make sure to wait until that time? Thread safety is not a problem race condition is not a serious problem if it occurs 1 or 2 times.
@ShrirajHegde Thanks for the hint. I will be thinking about this and implementing it. Sounds good though.
@lovvskillz Hey, don't forget to publish the current fix to PyPI since the issue is serious.
https://discord.com/developers/docs/topics/rate-limits#exceeding-a-rate-limit
According to this document, "retry_after" is the number of seconds in float.
This should prevent getting temporary bans.
Fixes #134