Manuel Astudillo

> Considering that #14 has been open for almost 5 years, how would you feel about releasing something like this PR to allow for custom JSON serializers? I created that...

I think you are going to enter a rabbit hole trying to start workers when you detect there may be jobs in the queue. BullMQ is designed to always have...

I think this is a case of the multiple parents feature request that some people have been requesting in the past. Unfortunatelly not supported. I am not sure if in...

Ok. We will need to have some kind of failback when this method fails, since it is not critical, just used to name the different workers.

As a workaround, you could monkey patch ioredis so that the ```client``` method becomes a noop, since I have yet not a nice solution for this.

Thanks for this reports. A couple of things, the QueueScheduler instance is not required after version 2.0 of BullMQ. Secondly, repeatable jobs are much more stable in v5, so this...

We deprecated "immediately" on repeat recently but have not yet updated the documentation, thank you for posting this to remind me. The current behaviour is as if immediately is always...

@robincsamuel The documentation states precisely that, so AFAICS it is correct. If you need the jobs to repeat at given points in time line at every starting minute you can...

@robincsamuel yes, you are right, but thats the old behaviour if you scroll a bit you can find this: 

@clemens All the points you wrote are true when using pattern. The default behaviour of immediately is just for the "every" option.