Repository navigation
Handle RATE_LIMIT_HIT (Rate limit exceeded) errors #773
Description
It would be nice if this library handled RATE_LIMIT_HIT errors automatically by sleeping for retry-after seconds and retrying the request. Otherwise this logic needs to be implemented in every user application.
Activity
i-ky commentedon Jan 18, 2023
@zulipbot add "enhancement" "help wanted"
Fahdmoh01 commentedon Oct 1, 2023
@zulipbot claim
zulipbot commentedon Oct 1, 2023
Welcome to Zulip, @Fahdmoh01! We just sent you an invite to collaborate on this repository at https://github.com/zulip/python-zulip-api/invitations. Please accept this invite in order to claim this issue and begin a fun, rewarding experience contributing to Zulip!
Here's some tips to get you off to a good start:
As you work on this issue, you'll also want to refer to the Zulip code contribution guide, as well as the rest of the developer documentation on that site.
See you on the other side (that is, the pull request side)!
Fahdmoh01 commentedon Oct 1, 2023
@i-ky does the Rate limit has to do with the message_limit?
i-ky commentedon Oct 1, 2023
Sorry, I am not familiar with Zulip's internals. What is
message_limityou are talking about?Fahdmoh01 commentedon Oct 1, 2023
message_limit is a variable inside the Ratelimit class of the zulip python api. where do I go to ask for further clarification for this issue?
i-ky commentedon Oct 1, 2023
I can only clarify what I propose to be changed from a python-zulip-api user's perspective, how it is to be changed from python-zulip-api perspective is a different matter.
timabbott commentedon Oct 1, 2023
This need to be done as an option -- some clients might very much not want to have sleeps of this form be part of what might happen.
I suppose there's also a question of whether we want the semantics to be to automatically retry the operation that failed due to the rate limit, or something else.
We also need to be cautious in implementing documenting this sort of thing to make sure we don't end up with bugged clients hitting the server exactly as often as the rate limits allow - that can generate a lot more useless load than something that doesn't retry. Probably this is not too hard to manage.
zulipbot commentedon Oct 14, 2023
@Fahdmoh01 You have been unassigned from this issue because you have not made any updates for over 14 days. Please feel free to reclaim the issue if you decide to pick up again. Thanks!
45 remaining items
zulipbot commentedon Oct 9, 2026
@devnishantt You have been unassigned from this issue because you have not made any updates for over 14 days. Please feel free to reclaim the issue if you decide to pick up again. Thanks!
devnishantt commentedon Oct 9, 2026
Still working on this. The PR is up and waiting for review:
#924
Happy to revise if a reviewer asks for changes.
devnishantt commentedon Oct 14, 2026
@zulipbot claim
PR is already open and waiting for review:
#924
zulipbot commentedon Oct 24, 2026
@devnishantt You have been unassigned from this issue because you have not made any updates for over 14 days. Please feel free to reclaim the issue if you decide to pick up again. Thanks!
Aditya-XR commentedon Nov 14, 2026
@zulipbot claim
zulipbot commentedon Nov 14, 2026
Welcome to Zulip, @Aditya-XR! By picking up a Zulip issue, you're promising to do your best to follow Zulip's contributing guidelines. Neglecting to do so wastes maintainer time, and may result in being banned from contributing to Zulip.
To get started:
The issue will be assigned to you when all three steps have been completed. If you get stuck, you can always
@zulipbot abandonthis issue, and pick a different one.If someone else claims this issue while you're working through the checklist, no worries! You can contribute by providing feedback on their pull request. If you’ve made good progress in understanding part of the codebase, you can also find another “help wanted” issue in the same area to work on.
Aditya-XR commentedon Nov 14, 2026
Here's my plan for tackling this based on the earlier discussion in #908:
auto_retry_rate_limits: bool = Falseflag toClient.__init__so existing callers that expectdo_api_queryto return theRATE_LIMIT_HITerror dict immediately aren't blocked by default.Client.do_api_query, check forres.status_code == 429whenself.auto_retry_rate_limitsis enabled, parse theRetry-Afterheader (falling back to1.0s if it's missing or invalid), sleep for that duration, and retry the request.zulip/tests/test_rate_limit.pymockingsession.requestandtime.sleepto cover the default behavior, retrying withRetry-After, and the fallback when the header is missing/malformed.I've opened #946 with this implementation.