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!
32 remaining items
tenzindayoe commentedon Jul 18, 2026
@zulipbot claim
zulipbot commentedon Jul 18, 2026
Welcome to Zulip, @tenzindayoe! 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.
zulipbot commentedon Jul 28, 2026
@tenzindayoe 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 Sep 29, 2026
@zulipbot claim
I'd like to add an opt-in Client(auto_retry_rate_limits=True) so 429 /
RATE_LIMIT_HIT sleeps for retry-after (plus jitter) and retries up to 10
times. Default stays False so callers that cannot block are unchanged.
#908 had the same idea and was closed unreviewed.
zulipbot commentedon Sep 29, 2026
Welcome to Zulip, @devnishantt! 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.
zulipbot commentedon Oct 9, 2026
@devnishantt We noticed that you have not made any updates to this issue or linked PRs for 10 days. Please comment here if you are still actively working on it. Otherwise, we'd appreciate a quick
@zulipbot abandoncomment so that someone else can claim this issue and continue from where you left off.If we don't hear back, you will be automatically unassigned in 4 days. 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.