-
-
Notifications
You must be signed in to change notification settings - Fork 368
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
6.3.2 breaks BullMQ-Pro lib #849
Comments
Hi, I can check alternative ways, it is a breaking change, since we don't support bullmq-pro officially. |
thanks, I know you don't want to support pro features, but it would be great if it still worked for the regular stuff. if you need anything from my side about what is in the QueuePro object, let me know. Appreciate it! |
Yeah, can you share how can i distinguish a ProQueue? |
the only thing i can think of right now is I don't "love it" but it would work? |
I've checked that |
Can u test |
working well, thank you! |
For the record, the version field appeared last month in bullmq 5.20, previous versions (still 5.x) will experience this |
Thank for the notice... I'll add an additional check |
Hi, we use bullmq pro for the group features, and your dashboard has been wonderful to use. But it seems 6.3.2 broke the ability to attach to bullmq-pro queues here: d0e42c7
setup a new QueuePro:
const queue = new QueuePro(queuename, queueoptions);
reference that queue when setting up a new bull-board:
queues: _.map(queues,(q) => new BullMQAdapter(q))
and it throws "You've used the BullMQ adapter with a non-BullMQ queue"
Assuming this is because of the type is QueuePro, would there be a different check that could be used?
instead of if
(!(queue instanceof BullQueue))
could use "libName" from the queue object? in pro it's just "bullmq-pro"? or anything similar?The text was updated successfully, but these errors were encountered: