-
Notifications
You must be signed in to change notification settings - Fork 20
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
Retry on ratelimit status #217
Conversation
@@ -75,6 +76,19 @@ export type RetryConfig = | |||
* ``` | |||
*/ | |||
backoff?: (retryCount: number) => number; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From the comments, I couldn't understand the usecase for the normal backoff. I know ratelimit is applied for 429, but what is this for? Maybe we can explain a bit more in the docstring
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's for when fetch throws an error, instead of returning a response with some status (200 or non-200)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh ok, after reading the code I understood, a little note in the comments would be very helpfull
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated docs 👍
decided to close this PR and update the default retry duration to be 1 sec in the second retry |
With this PR, we update the qstash-js client to retry ratelimit errors. The client will retry with this algorithm by default
In a nutshell, it's the max of
last backoff + 1s
and1-5s
. The aim is to spread the load over time while keeping the durations small.