-
-
Notifications
You must be signed in to change notification settings - Fork 196
Allow changing intervalCap
later
#233
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
base: main
Are you sure you want to change the base?
Conversation
Needs a test for when toggling infinite to finite mid-interval.
|
return this.#intervalCount; | ||
} | ||
|
||
set intervalCap(value: 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.
Removing the cap mid-interval must claer ratelimit state. When setting intervalCap = Number.POSITIVE_INFINITY
, you switch to “interval ignored.” You do call #processQueue()
, but if #rateLimitedInInterval
or #rateLimitFlushScheduled
are set, they can still throttle execution until the old timeout fires. Reset those flags when the cap becomes infinite, then process.
|
||
The max number of runs in the given interval of time. | ||
|
||
Can be changed later by setting `queue.intervalCap`. If changed in the middle of a running interval, the new cap applies immediately. If the new cap is lower than the used cap, the "debt" is not carried over into the next interval. |
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.
"Debt is not carried over into the next interval" is bit unclear. Say exactly what happens:
If the new cap is lower than the number already run in the current interval, no more tasks start until the next interval begins.
Co-Authored-By: Sindre Sorhus <[email protected]>
#177