You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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.
The text was updated successfully, but these errors were encountered: