-
Notifications
You must be signed in to change notification settings - Fork 386
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
[Bug]: Windows sandboxed processors broke in 4.15.2 and onward #2372
Comments
Additional Information: When using node.js to resolve ESM imports, absolute paths are treated as a URL in all environments. In order to fix without reverting the d97a5e0 commit, using a file:// url must be supported. However, there is currently a file existence check in bullmq which blocks being able to do this:
|
Note that my app is using CJS and not ESM. For the CJS build, all of these issues go away if the processor uses require, instead of import
|
@roggervalf, after further investigation, it appears newer versions of bull now supports passing a URL object as the processor. When specifying the processor in this way, it works as expected on Windows. Specifying the file as a raw path string, per the docs, is no longer supported. Now invalid: https://docs.bullmq.io/guide/workers/sandboxed-processors Working example:
|
With the documentation in PR #2373, this issue can be closed. |
Version
v4.15.2
Platform
NodeJS - v18.18.0
What happened?
When creating a sandboxed processor pool in Windows, using an absolute path, an error will occur when the child is spawned. This will cause the job to fail immediately, and then the Child is put into a non-working state.
This does not seem to occur in a Linux environment.
I have tracked the regression to this commit:
d97a5e0
If this is no longer the correct way to specify the worker script, please suggest the correct approach and update the docs.
How to reproduce.
Example:
Relevant log output
Code of Conduct
The text was updated successfully, but these errors were encountered: