Files
Jimmy MillerandGitHub 0722c225ca Fix workers on thread to not crash with napi-rs (#95281)
We believed the workers were crashing due to issues related to node. We
had code that guarded on which version of node you were using and warned
that it was unstable. I was able to recreate the crashes regardless of
node version or napi-rs version. I filed an issue with napi-rs
https://github.com/napi-rs/napi-rs/issues/3357.

This gets around the crashes we were seeing by making sure we don't drop
things off isolate causing these bugs. I did explore writing some tests
here, but I wasn't sure a good way to do that. I did make
[jimmym/turbopack-loader-worker-changes-stress-test](https://github.com/vercel/next.js/tree/jimmym/turbopack-loader-worker-changes-stress-test)
which has a nice little reproducing stress test that now passes. I
wasn't sure if we'd want something like this checked in or not. But
figure it is good for people to see.

I probably do need to validate this with some existing apps out there
that trigger the crash. But I did keep the default to the process
workers for now, so impact should be minimal.
2026-06-30 15:38:34 -04:00

34 lines
924 B
TypeScript

import { nextTestSetup } from 'e2e-utils'
describe.each([
['workerThreads', true],
['childProcesses', false],
] as const)(
'turbopack-node-backend (%s)',
(turbopackPluginRuntimeStrategy, expectSamePid) => {
const { next, isTurbopack } = nextTestSetup({
files: __dirname,
env: {
TEST_TURBOPACK_PLUGIN_RUNTIME_STRATEGY: turbopackPluginRuntimeStrategy,
},
})
const itOnlyTurbopack = isTurbopack ? it : it.skip
itOnlyTurbopack('should match expected loader pid behavior', async () => {
const response = await next.fetch('/api/pid')
expect(response.status).toBe(200)
const data = await response.json()
expect(data.buildPid).toBeDefined()
expect(data.loaderPid).toBeDefined()
if (expectSamePid) {
expect(data.loaderPid).toBe(data.buildPid)
} else {
expect(data.loaderPid).not.toBe(data.buildPid)
}
})
}
)