-
Notifications
You must be signed in to change notification settings - Fork 29k
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
Stop throwing for unsupported options in Worker
's execArgv
and env.NODE_OPTIONS
.
#41103
Comments
@nodejs/workers |
Worker
's execArgv
.Worker
's execArgv
and env.NODE_OPTIONS
.
The same happens with When running const { Worker, isMainThread } = require("worker_threads");
if (isMainThread) {
new Worker(__filename);
} else {
console.log("From worker!", process.env.NODE_OPTIONS);
} but this throws const { Worker, isMainThread } = require("worker_threads");
if (isMainThread) {
new Worker(__filename, { env: process.env });
} else {
console.log("From worker!", process.env.NODE_OPTIONS);
} |
This may be not right, as: const { isMainThread, Worker } = require("worker_threads");
if (isMainThread) {
new Worker(__filename, {
execArgv: []
});
} else {
console.log("Hello from the worker!", process.execArgv, globalThis.gc);
} run
Seems that this behavior is not controlled by work's |
If Lines 551 to 553 in 4cb2a47
Lines 308 to 315 in 4cb2a47
But since these Per-Process options and V8 flags are from parents, I guess it is ok? |
this have for sure been bugging me too, some flags gets added or removed in different versions. |
Just ran into this using |
What's the word on this? Just hit this on taskforcesh/bullmq#2075 which is a pain because without a change to that package, worker_threads can't be used. |
+1 for Ignore the unsupported options |
Opened #53596 for the simpler case of NODE_OPTIONS, when the worker spawning code does not intend to modify NODE_OPTIONS and only copies the one from the parent because they want to update other environment variables. |
When the worker spawning code copies NODE_OPTIONS from process.env, previously we do a check again on the copied NODE_OPTIONS and throw if it contains per-process settings. This can be problematic if the end user starts the process with a NODE_OPTIONS and the worker is spawned by a third-party that tries to extend process.env with some overrides before passing them into the worker. This patch adds another exception that allows the per-process options in the NODE_OPTIONS passed to a worker if the NODE_OPTIONS is character-by-character equal to the parent NODE_OPTIONS. While some more intelligent filter can be useful too, this works good enough for the inheritance case, when the worker spawning code does not intend to modify NODE_OPTIONS. PR-URL: nodejs#53596 Refs: nodejs#41103 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Xuguang Mei <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]>
When the worker spawning code copies NODE_OPTIONS from process.env, previously we do a check again on the copied NODE_OPTIONS and throw if it contains per-process settings. This can be problematic if the end user starts the process with a NODE_OPTIONS and the worker is spawned by a third-party that tries to extend process.env with some overrides before passing them into the worker. This patch adds another exception that allows the per-process options in the NODE_OPTIONS passed to a worker if the NODE_OPTIONS is character-by-character equal to the parent NODE_OPTIONS. While some more intelligent filter can be useful too, this works good enough for the inheritance case, when the worker spawning code does not intend to modify NODE_OPTIONS. PR-URL: #53596 Refs: #41103 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Xuguang Mei <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]>
When the worker spawning code copies NODE_OPTIONS from process.env, previously we do a check again on the copied NODE_OPTIONS and throw if it contains per-process settings. This can be problematic if the end user starts the process with a NODE_OPTIONS and the worker is spawned by a third-party that tries to extend process.env with some overrides before passing them into the worker. This patch adds another exception that allows the per-process options in the NODE_OPTIONS passed to a worker if the NODE_OPTIONS is character-by-character equal to the parent NODE_OPTIONS. While some more intelligent filter can be useful too, this works good enough for the inheritance case, when the worker spawning code does not intend to modify NODE_OPTIONS. PR-URL: #53596 Refs: #41103 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Xuguang Mei <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]>
I came across this error while building angular 18 app. I solved it by disabling SSR "prerender": false, "ssr": false inside project.json file |
When the worker spawning code copies NODE_OPTIONS from process.env, previously we do a check again on the copied NODE_OPTIONS and throw if it contains per-process settings. This can be problematic if the end user starts the process with a NODE_OPTIONS and the worker is spawned by a third-party that tries to extend process.env with some overrides before passing them into the worker. This patch adds another exception that allows the per-process options in the NODE_OPTIONS passed to a worker if the NODE_OPTIONS is character-by-character equal to the parent NODE_OPTIONS. While some more intelligent filter can be useful too, this works good enough for the inheritance case, when the worker spawning code does not intend to modify NODE_OPTIONS. PR-URL: #53596 Refs: #41103 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Xuguang Mei <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]>
When the worker spawning code copies NODE_OPTIONS from process.env, previously we do a check again on the copied NODE_OPTIONS and throw if it contains per-process settings. This can be problematic if the end user starts the process with a NODE_OPTIONS and the worker is spawned by a third-party that tries to extend process.env with some overrides before passing them into the worker. This patch adds another exception that allows the per-process options in the NODE_OPTIONS passed to a worker if the NODE_OPTIONS is character-by-character equal to the parent NODE_OPTIONS. While some more intelligent filter can be useful too, this works good enough for the inheritance case, when the worker spawning code does not intend to modify NODE_OPTIONS. PR-URL: #53596 Refs: #41103 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Xuguang Mei <[email protected]> Reviewed-By: Chengzhong Wu <[email protected]>
I ran into this when building an old project that uses mocha-parallel-test and node's --openssl-legacy-provider option. Either node should ignore these options by default, as it appears to when using the default execArgv, or node should provide a function to remove unsupported options, or return |
Version
v17.2.0
Platform
No response
Subsystem
worker_threads
What steps will reproduce the bug?
Consider this
test.js
file:Run these two commands:
They will log
Now, uncomment the
execArgv: process.execArgv
line and run the two commands again. The first command will still loghowever, the second one throws:
This mans that the default behavior of the Worker
execArgv
option is not to inheritexecArgv
from the parent thread (contrary to what the documentation says).Why would you want to explicitly pass
execArgv: process.execArgv
anyway?A few days ago I was trying to implement a require hook that internally uses a
Worker
, and in order to avoid registering it recursively in an infinite worker-spawn loop I tried to filter out the--require
flag:this seemed to work, until it crashed in a test that was using the
--expose_gc
option.Today, I found the exact same problem in
jest-worker
(a Jest subpackage that is often also used outside of Jest): jestjs/jest#12103 was opened becausejest-worker
didn't work when running Node.js with--max_old_space_size
.Since Node.js doesn't provide the list of flags supported by workers progrmmatically (and I didn't find it in the docs either 😅) there is no way to filter the
execArgv
used by a worker.What is the current behavior?
I initially expected the real default behavior to be something like
execArgv: process.execArgv.filter(isSupportedByWorker)
, but it looks like it's not either. Consider for example the--expose_gc
(which is disallowed in workers) option with this example:If you run
node --expose_gc test.js
, it will logYou can see that the
gc
function is present. This means that the disallowed flags are not ignored (and not even "ignored but still used to populate theprocess.execArgv
array): they are used and affect the runtime behavior.How often does it reproduce? Is there a required condition?
Only for the options marked as "unsupported" in workers.
What is the expected behavior?
I see four possible solutions:
execArgv
).execArgv
of the parent thread.execArgv: process.execArgv
becomes the default behavior), and provide aWorker.filterExecArgv
utility that removes disallowed options, and that I would have used likeIf the current behavior is expected, then the docs should be updated to mention that the default value cannot be replicated by explicitly passing an
execArgv
option.What do you see instead?
No response
Additional information
No response
The text was updated successfully, but these errors were encountered: