bull
bull copied to clipboard
OptimalBits
Feature request: change rate limit of an active queue
Description
As much as some don't think so, this is very useful. There are cases of APIs that change the usage quota depending on the demand they are receiving, and, in most cases, closing and creating a new queue would simply not be an interesting option. At least for these cases, it would be very useful to be able to change the rate limit on active queues.
Please consider adding this feature.
This could be a candidate for version 3.0, where we plan to remove rate-limit by groups and improve the current global rate limiter. With the new rate limiter it would be pretty easy to implement this feature.
As a note for future implementers: The idea is that from inside the job processor we should be able to programmatically rate limit the queue, so for example, if the job called an API and such API returned 429 (Too Many), the processor could call this method to rate-limit the queue, and put this job back to "wait" since we want to retry this same job later when the queue is not rate limited anymore.
Great! I'm very happy with this!
I had to deal with this kind of situation again in the last few weeks, and it was a real nightmare.
One additional note I found valid after discussing this with colleagues and the last use case we had to deal with: the processor needs to consider changes to increase and to decrease the rate-limit effectively.
Opening up only the possibility of temporary reductions (returning to an initial state), for example, would only partially solve the problem.
In the last case that I worked on, there were constant fluctuations, of decrease and increase (above the initial quota), due to the demand for the company's internal API and other conditions checked by such API during execution time.
It's just a case that I'm mentioning as an example, but it illustrates the importance of having both possibilities available. It is extremely necessary to make it possible to increase and decrease the rate-limit of active queues.
Yes, this is coming in BullMQ 3.0: https://blog.taskforce.sh/rate-limit-recipes-in-nodejs-using-bullmq/ But we are not going to backport this feature to Bull since it requires a lot of changes.