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
[ ] Regression
[x] Bug report
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.
Current behavior
In the current design of Bull, the concurrency is managed at the processor level and does not allow to easily configure a single queue with no concurrency used by multiple named processors.
Given the fact that concurrency of each processor stacks up for the queue, a workaround exists and consists of defining a concurrency to 0 to every processor of the queue expected the first one. The workaround is described here: OptimalBits/bull#1113.
Using the NestJS/Bull decorator, the code below should do the trick
I'm submitting a...
Current behavior
In the current design of Bull, the concurrency is managed at the processor level and does not allow to easily configure a single queue with no concurrency used by multiple named processors.
Given the fact that concurrency of each processor stacks up for the queue, a workaround exists and consists of defining a concurrency to 0 to every processor of the queue expected the first one. The workaround is described here: OptimalBits/bull#1113.
Using the NestJS/Bull decorator, the code below should do the trick
However, any argument with a falsy value is rejected before calling
queue.process
with the options of the decorator (https://github.com/nestjs/bull/blob/master/lib/bull.explorer.ts#L82).Expected behavior
Concurrency options with a 0 value should be a valid option and should not be rejected by the
@Processor
decorator.could be changed to
Environment
The text was updated successfully, but these errors were encountered: