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

Understand rate-limiting responses (429, RATE_LIMIT_HIT) #946

Open
gnprice opened this issue Sep 17, 2024 · 0 comments
Open

Understand rate-limiting responses (429, RATE_LIMIT_HIT) #946

gnprice opened this issue Sep 17, 2024 · 0 comments
Labels
a-api Implementing specific parts of the Zulip server API
Milestone

Comments

@gnprice
Copy link
Member

gnprice commented Sep 17, 2024

The Zulip server rate-limits requests. By default the limit for each user is 200 per minute, in total across all types of requests. For an example where this came up, see #945 and its original report.

We'll resolve #945 by having fetchOlder specifically add backoff for the getMessages requests we make there. But then a further bonus refinement would be for us to understand when the server is specifically giving us rate-limiting errors, and follow its instructions for how long to wait before making another request.

For docs on the rate-limiting errors:

To do this right, this logic belongs on ApiConnection. That way the information can be shared across all the different requests we make on behalf of a given account.

@gnprice gnprice added the a-api Implementing specific parts of the Zulip server API label Sep 17, 2024
@gnprice gnprice added this to the Post-launch milestone Sep 17, 2024
gnprice added a commit to gnprice/zulip-flutter that referenced this issue Nov 16, 2024
This covers a particular case of zulip#946.

This commit is actually NFC as far as the interaction with the server
goes; its only change in behavior is that we treat the error as
"expected", and therefore skip reporting it to the user unless it
follows a string of other errors.

But then this also sets us up so that these rate-limit errors will
continue to be handled with backoff-retry when we change the handling
of unexpected errors, coming next.
gnprice added a commit that referenced this issue Nov 20, 2024
This covers a particular case of #946.

This commit is actually NFC as far as the interaction with the server
goes; its only change in behavior is that we treat the error as
"expected", and therefore skip reporting it to the user unless it
follows a string of other errors.

But then this also sets us up so that these rate-limit errors will
continue to be handled with backoff-retry when we change the handling
of unexpected errors, coming next.
@gnprice gnprice modified the milestones: M6: Post-launch, M7: Future Nov 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a-api Implementing specific parts of the Zulip server API
Projects
Status: No status
Development

No branches or pull requests

1 participant