Manuel Astudillo
Manuel Astudillo
By default ```worker.close``` will wait for the current jobs to complete, maybe your jobs are not completing in the test, or taking too much time?
I have been able to reproduce this and after a few hours trying with wtfnode I managed to improve it a bit but it all seems to boil down in...
Another thing, using ```--detectOpenHandles``` as Jests suggests does not work so well either, it does not give you any further information, BUT it does not give the error either so...
We could finally merge the PR #2656 after Dragonfly fixed an issue that prevented the tests from running. Hopefully the close sequence is more robust now.
I am closing now, please re-open if it is not working for you.
I understand your frustration, but BullMQ does not keep old code anywhere. Probably you have some old worker that is still working and you are not aware of it. By...
> One more question, if we had 2 different versions of processes running, could the @OnQueueEvent('failed') event be fired in the process which did not result the failed job? You...
> If the job is failed and has backoff strategy with attempts, will the new attempts use new processor code? If the removeOnFail is 1h, will the job fire new...
@roggervalf I think we need a new method or expand the current ```getDelayedCount``` so that it takes in a "timestamp" and returns the count of all the delayed jobs with...
It would be a nice addition.