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

Update workerpool #203

Closed
wants to merge 6 commits into from
Closed

Update workerpool #203

wants to merge 6 commits into from

Conversation

mansona
Copy link

@mansona mansona commented Jun 6, 2021

Over the last week or so, I have been tracking down an issue that prevented some Ember apps from working/building in Node 16. After a conversation with @Turbo87 on Discord we thought that we should update the workerpool sub-dependency of ember-cli-babel@6 because that was causing the underlying issue.

I have successfully tested the change in this PR by updating the broccoli-babel-transpiler dependency to target this branch in a PR/branch in ember-cli-babel and then subsequently doing some manual(ish) yarn.lock manipulation to force an application to use that ember-cli-babel branch. You can check out the changes in this PR: ember-fastboot/ember-cli-fastboot#834 and the fact that the tests are passing should be a good indication that the experiment has worked 🎉

This PR does the following:

  • updates the workerpool dependency to latest (v6.1.0 had the fix we needed)
  • updates calls to workerpool.pool to include workerType because the default changed (and I set it to what it would have been)
  • fixed some assertions in tests because the messages didn't quite match (they seem to have expected just a message but were getting a full stack trace instead 🤷 )
  • cherry-picked updates to the CI because this PR is targeting the v6 release branch and those changes weren't made before it was cut

If we agree with my approach then we would need to cut a new v6 patch (or minor?) release after this is merged.

Let me know if you have any questions 👍

@mansona mansona marked this pull request as ready for review June 10, 2021 09:30
Copy link
Member

@rwjblue rwjblue left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tests aren’t running (GH Actions won’t run when added in a fork). Let’s do the CI changes in a separate PR, all by themselves. Then we can rebase this against those changes and confirm things actually pass.

pool = workerpool.pool(path.join(__dirname, 'worker.js'), { maxWorkers: JOBS });
pool = workerpool.pool(path.join(__dirname, 'worker.js'), {
maxWorkers: JOBS,
workerType: 'process'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why force process here? If thread is available I don’t see why we’d want to force process.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well tests fail if we don't 😂 I don't really understand why, I was trying to do the minimum effort to get this passing

Copy link
Member

@stefanpenner stefanpenner Jun 11, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thread is the preferred approach here... fallback to process only when absolutely needed.

@@ -44,7 +44,7 @@
"heimdalljs-logger": "^0.1.7",
"json-stable-stringify": "^1.0.0",
"rsvp": "^4.8.2",
"workerpool": "^2.3.0"
"workerpool": "^6.1.4"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is breaking in a way that we typically do not do... 🤔

Specifically, this is changing an old major to drop support for a Node major version with the expectation of releasing without a breaking change indication. This is likely to cause exactly the kind of breakage you are trying to fix (introduced CI failures).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I wasn't intending to drop support for any node version 🤔 the idea was that the tests should still check the correct Node version. I guess technically because workerpool aren't testing against our supported Node versions they could break older ones at any time, is that what you mean?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess technically because workerpool aren't testing against our supported Node versions they could break older ones at any time, is that what you mean?

Yes, exactly. They could update to (for example) async/await syntax, which would be breaking for Node 8 users (which ember-cli-babel@6 still supports).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO, the right fix (as I mentioned in #203 (review)) is to disable parallelizing when running on Node 16. It is the least invasive change, and has the least likely hood of breaking folks.

strategy:
matrix:
os: ['ubuntu', 'windows', 'macOS']
node: ['10', '12', '14']
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn’t test node 16 (which is theoretically the point?)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes you're right I should have added that. I'll split the CI stuff and then add 16 in this PR when it's rebased 👍

Copy link
Member

@rwjblue rwjblue left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we think this is critical to fix, versus just saying Node 16 is the end of the line for folks that haven’t updated to ember-cli-babel@7 (which is very old at this point), I’d rather just drop support for parallelizing when running on Node 16 (and not change the workerpool dependency).

That would be done by making this return false when on Node 16:

isParallelizable: isSerializable(options),

@stefanpenner
Copy link
Member

updates the workerpool dependency to latest (v6.1.0 had the fix we needed)

What exactly was the fix? It may be practical to backport to an older workerpool.

@mansona
Copy link
Author

mansona commented Jun 14, 2021

So this was the change that fixed it in Node 16: https://github.com/josdejong/workerpool/pull/230/files

I had a quick look and it does seem like we could backport it because the same code does exist https://github.com/josdejong/workerpool/blob/v2.3.3/lib/WorkerHandler.js#L174 but I'm not entirely sure which part of it was failing 🤔 we couldn't use the same code change.

I was going to just try what @rwjblue was suggesting next i.e. remove the call to workerpool for any Node version > 14

@stefanpenner
Copy link
Member

@mansona if you can backport, I can release

@mansona
Copy link
Author

mansona commented Jun 14, 2021

@stefanpenner it looks like the backport actually works as-is 😱 I have a branch that I've tested in Node 6 and Node 16 https://github.com/mansona/workerpool/tree/fix-node-16

Can you create a v2 release branch so that I can target it with a PR?

@SergeAstapov
Copy link

SergeAstapov commented Sep 29, 2021

@mansona @stefanpenner @rwjblue workerpool@2.3.4 patch version was released. Does it mean we need to proceed with this PR?

I would assume, we only need to migrate Travis -> GH Actions.

workerpool was already upgraded to ^6.x in #190 already and package.json in master has "workerpool": "^6.0.2"
just realized this targets 6.x version

@lifeart
Copy link

lifeart commented Dec 23, 2021

@mansona @stefanpenner ping, any help needed here?

@kevinkucharczyk
Copy link

kevinkucharczyk commented Jan 26, 2022

@mansona @stefanpenner @rwjblue sorry for pinging you again - is there a way to move this PR forward?

@rwjblue
Copy link
Member

rwjblue commented Apr 7, 2022

Closing as the fix (and a patch release) landed in the older version of workerpool

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

Successfully merging this pull request may close these issues.

6 participants