Windows sandboxed processors broke

[Mystos]

Is there an existing issue for this?

• [X] I have searched the existing issues

Current behavior

When you register a new Queue for sandboxed process on windows, the job will failed instantly when spawned.

I've found out that bullMQ had this issue => https://github.com/taskforcesh/bullmq/issues/2372

It was resolved by accepting URL object.

Also in "bull.provider" there is the creation of workers via the processor options. But there is 4 checks :

• isAdvancedProcessor
• isAdvancedSeparateProcessor
• isSeparateProcessor
• isProcessorCallback

And apparently if you have and URL object, none of the 4 checks go throught.

Should an PR be done to fix this issue ? And could there be other modification to be think of ?

I'm not really experienced in node and nest so sorry if I have overlook something.

Minimum reproduction code

https://github.com/Mystos/bull-nest-windows-sandboxed-error

Steps to reproduce

No response

Expected behavior

The sandboxed worker should accept URL object and string path to the processor file.

Package version

10.1.1

Bull version

5.7.8

NestJS version

10.0.0

Node.js version

No response

In which operating systems have you tested?

• [ ] macOS
• [X] Windows
• [ ] Linux

Other

No response

[kamilmysliwiec]

Would you like to create a PR for this issue?

[Mystos]

@kamilmysliwiec I may be a bit too unfamiliar with NestJS and Node to do it. I've tried to do a quick fix, but I run into some TS problems that I can't find a solution for. If anyone more experienced would do it, I guess it could be better.

[p29kow]

I was working on a project yesterday when i came across the problem. Luckily, i created a solution that worked for me. I modified the BullQueueProcessor type to also accept a URL. I then went to the helpers file and included a logical OR in the "isSeparateProcessor" function. That way, it checks if the value provided is a string or a URL instance. Hope this helps. I'll create a PR shortly