Skip to content
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

Worker threads crash when unexpected execArgv are passed #8673

Closed
maxpolun opened this issue Dec 5, 2022 · 1 comment
Closed

Worker threads crash when unexpected execArgv are passed #8673

maxpolun opened this issue Dec 5, 2022 · 1 comment

Comments

@maxpolun
Copy link
Contributor

maxpolun commented Dec 5, 2022

I'm running parcel as a bundler under moonrepo, and one thing it does is set the process's title via the node arg --title [task name]. This should be fine for a regular node process, but parcel dies by default since it will try and use worker threads, and pass the node process args (in process.execArgv) to the worker thread's execArgv. However node worker threads will crash if given an unexpected execArgv, so the whole process crashes with an error like

Error [ERR_WORKER_INVALID_EXEC_ARGV]: Initiated Worker with invalid execArgv flags: --title

I'm currently working around this issue by setting PARCEL_WORKER_BACKEND=process, but it took me quite a while to figure this out.

I'd say there are 3 options I can think of to improve this:

  1. filter out any options known to throw (process level args, v8 tuning args)
  2. just pass an empty list explicitly (so there's no execArgv in the child)
  3. Catch the error on creating the worker and have a better error message (including mentioning PARCEL_WORKER_BACKEND)

I lean towards 2, just because it's simpler, will not break even with new options, and I don't think there's many execargv options that work with workers anyways, but I leave it to the project to decide.

There is an issue in the node repo to change this behavior (which would be ideal), but it's been open for like a year: nodejs/node#41103

If one of these approaches sounds good, I can make a PR, they all seem pretty straightforward.

@mischnic
Copy link
Member

Option 1 is what we've been doing so far, so I'd say we just continue with that for now.
There has been a similar PR in the past: #5017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants