Jest: globalTeardown not called when stopping jest via ctrl+c

[ansgarm]

Hey, I want to report a bug / missing feature (depends on the point of view).

Current behavior
When you cancel jest via ctrl + c the globalTeardown hook is not called.

Minimal example
https://github.com/ansgarm/jest-global-teardown-bug

Expected behavior
The globalTeardown hook should be called.

Run npx envinfo --preset jest in your project directory and paste the
results here
System:
OS: macOS High Sierra 10.13.1
CPU: x64 Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz
Binaries:
Node: 8.9.3 - ~/.nvm/versions/node/v8.9.3/bin/node
Yarn: 1.3.2 - ~/.yarn/bin/yarn
npm: 5.7.1 - ~/.nvm/versions/node/v8.9.3/bin/npm
npmPackages:
jest: ^22.4.3 => 22.4.3

Best!
Ansgar

[SimenB]

We don't do any signal handling in Jest. @cpojer do we want to?

[cpojer]

Happy to accept a PR for this.

[ansgarm]

Cool, will do!

[SimenB]

should it behave the same as a normal interrupt in watch mode? Or should we interrupt, cleanup, and shut down?

[ansgarm]

Just noticed, that the same thing happens when you use --bail. It then fails to run teardown aswell.

[binygal]

I'm working on it but it seems like it not some trivial and probably need to do some architecture decisions. I would love to discuss it with someone.

[noomorph]

@binygal , I'm far from Jest project per se, but I am the interested side in such pull request as this issue poisons user experience in https://github.com/wix/detox (especially with the next @8.x.x version, in cases like when Ctrl+C does not stop video recording on Android devices since there is no chance to get enough time to send SIGINT to the recording process inside Jest test, remove temporary files, etc).

However, my two cents are that... actually, it is not necessary to guarantee afterAll execution. I would rather love to see a fix that returns a regular and normally expected behavior of process.on('SIGINT', () => ... (and SIGTERM) listeners in Jest tests.

Once I've been rummaging inside node_modules/jest-worker and saw that when it gets an exit signal from the parent, it simply does process.exit(0) and that's it. That made me assume that this is one of pain points that might be rewritten somehow.

[binygal]

It seems that I have the same problem as here - https://github.com/josdejong/workerpool/issues/36. When the parent process is interrupted and exit the jest workers keep running.
Seems like I need to actively end the workers when I get SIGINT.

[sheerun]

I also have the same issue when I use --bail (global teardown is not executed when some tests fail).

[unional]

This causes connection staving when I interrupt watch mode but the child process still going.
I have 10k of tests making 40k of calls.
Imagine what happens when I start and stop watch mode a few times.

[SimenB]

I wonder if a process.on('exit') handler would be enough.

We should definitely autoclose workers when the parent process exits, though, cc @mjesun

bail is different, that feels more like a straight up bug

[mzedeler]

Is this still an issue?

I just spelunked into the code and found this:

https://github.com/facebook/jest/blob/master/packages/jest-worker/src/workers/processChild.js#L113

[thymikee]

I don't think that's related

[goldo]

any news on this one ?

[pavoltravnik]

Can anyone explain why,
process.on('SIGINT', () => { console.log('SIGINT signal') })
is not executed while running jest and aborting job by ctrl+c?

[thomaseizinger]

Can anyone explain why,
process.on('SIGINT', () => { console.log('SIGINT signal') })
is not executed while running jest and aborting job by ctrl+c?

It is executed for me and this is how we are currently working around this problem :)

I am successfully registering this handler in the globalSetup handler!
However, if you exit right after the console.log it can happen that you don't see the console.log because it is not flushed fast enough :)