Manuel Astudillo
Manuel Astudillo
Not having a test for moveToDelayed was definitely an overlook from out part, we will fix it asap.
I actually checked in the codebase and there is indeed a test for moveToDelayed, you can use it for inspiration for your moveToWaitingChildren: https://github.com/taskforcesh/bullmq/blob/master/tests/test_sandboxed_process.ts#L892
thanks for reporting this, we are looking into it, it could just be that the typings are incorrect, but the method should be there.
We have a PR open for this but there is some small work to do before it is ready. Luckily tomorrow, or on Monday.
For the record, the reason this method is not available is because Pro always is delayed a few versions from latest BullMQ, unless we have done some critical fixes.
Thanks for your proposal. I think that in general it is better to leave the logging to the client of the library, for example listening to the proper events you...
If I have understood the code correctly, the forced timeout will only be applied if we pass the new blockingTimeout option explicitly. The main issues I see with this approach...
So the way to see this new option is like a fallback for this type of disconnections and nothing else. In this case I guess it is ok. I can...
Would it be possible to have a setter for this option so that it could be changed on an existing instance?
Something is wrong with this implementation, testing with this code: ```ts import Redis from "ioredis"; const port = 6379; const connection = new Redis({ host: "localhost", port, blockingTimeout: 1000, });...