Jest fails with Node Workers producing stderr/stdout output

[jacogr]

• Version: 10.6 (also fails on 10.5)
• Platform: Darwin Kernel Version 17.3.0
• Subsystem: workers

With Jest & Node 10.5+ (experimental) workers, any output in the worker to stdout/stderr makes the test fail. To clarify, the test itself passes, but the overall execution fails. Node cannot find the stream to write to at the end of execution, possibly due to Jest bufferring?

When the Worker has no writes to stderr/stdout output, everything works as expected.

$ NODE_OPTIONS=--experimental-worker jest
 PASS  ./index.spec.js
  worker test
    ✓ sends message to worker, retrieves result (1055ms)

  console.log index.js:21
    MASTER: sending request : 13 + 29

  console.log index.js:27
    MASTER: received result = 42

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        2.969s
Ran all test suites.
internal/worker.js:310
        return this[kParentSideStdio][stream].push(chunk, encoding);
                                     ^

TypeError: Cannot read property 'stdout' of null
    at Worker.[kOnMessage] (internal/worker.js:310:38)
    at MessagePort.Worker.(anonymous function).on (internal/worker.js:243:57)
    at MessagePort.emit (events.js:182:13)
    at MessagePort.onmessage (internal/worker.js:66:8)
error Command failed with exit code 1.

A repo with a reproduction is found here - https://github.com/jacogr/jest-node-worker

1. Ensure you have Node 10.5 or 10.6
2. Install dependencies (which is only jest)
3. yarn run test

It has also been logged with Jest at jestjs/jest#6646 (My first assumption was that it has to do with io buffers, but at the same time it fails internally to the Node workers implementation - so logging it here as well)

[jdalton]

You can remove jest from this entirely and repro the same issue by just reworking jacogr/jest-node-worker/index.js to message itself from node --experimental-worker ./index.js.

Update:

The issue is related to worker.terminate() use. There is warning in the docs about it:

Warning: Currently, not all code in the internals of Node.js is prepared to expect termination at arbitrary points in time and may crash if it encounters that condition. Consequently, you should currently only call .terminate() if it is known that the Worker thread is not accessing Node.js core modules other than what is exposed in the worker module.

[jacogr]

The terminate actually got added to work around another issues when testing - i.e. if the worker is not terminated, it hangs around and the test process also fails since "something is still active".

Going back to how I arrived at this, i.e. from the code where I used it, I do recall the worker doing output - that must have been before I had to add the terminate to tests then.

PS: In this case the terminate is called inside the function, which actually, as a test-case, does not quite match up with what I have in reality. In reality I have something like -

describe('test', () => {
  it('does something', () => {});
  // last test for termination
  it('terminates worker', () => {
    test.terminate(done);
  });
});

In the simplification I didn't expose an actual terminate call additionally.

[jacogr]

Calling worker.unref() first solves the issue. Closing.