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

Jest process doesn’t quit after last test completes #1456

Closed
calebmer opened this Issue Aug 18, 2016 · 41 comments

Comments

Projects
None yet
@calebmer
Contributor

calebmer commented Aug 18, 2016

I’m having issues with the Jest process not completing after the last test completes. The user will have to force quit the process with ctrl-c. My theory is that not all resources are being cleaned up appropriately by the test authors, but ideally Jest should quit anyway.

Specifically I’m testing Firebase with firebase-server, spinning up one or more servers for every test. In an afterEach action we call the close method for all the servers created in the last test, however even with this method the Jest process still doesn’t quit.

Is there a way to force the Jest process to quit once tests have finished (pass or fail)? Is there a way to get an afterAll hook to cleanup all leftover resources? Is there a way to debug what exactly keeps the Jest process from quitting? Thanks.

@cpojer

This comment has been minimized.

Show comment
Hide comment
@cpojer

cpojer Aug 18, 2016

Contributor

We don't have a good way to do that right now. I would recommend trying to hook in a debugger (Chrome Inspector) to figure out what is going on. If you know what creates the async work, you can potentially also monkey patch it and track it (like put something around Promise.prototype.then)

Contributor

cpojer commented Aug 18, 2016

We don't have a good way to do that right now. I would recommend trying to hook in a debugger (Chrome Inspector) to figure out what is going on. If you know what creates the async work, you can potentially also monkey patch it and track it (like put something around Promise.prototype.then)

@calebmer

This comment has been minimized.

Show comment
Hide comment
@calebmer

calebmer Aug 18, 2016

Contributor

Is there a reason async work can’t be force quit when all afterEach/after hooks have resolved?

Contributor

calebmer commented Aug 18, 2016

Is there a reason async work can’t be force quit when all afterEach/after hooks have resolved?

@cpojer

This comment has been minimized.

Show comment
Hide comment
@cpojer

cpojer Aug 18, 2016

Contributor

I don't know how you'd kill existing async processes if you don't have a handle on them.

Contributor

cpojer commented Aug 18, 2016

I don't know how you'd kill existing async processes if you don't have a handle on them.

@calebmer

This comment has been minimized.

Show comment
Hide comment
@calebmer

calebmer Aug 18, 2016

Contributor

I migrated from ava and this wasn’t a problem, so maybe there is an answer? Maybe that’s process.exit in Node.js

Contributor

calebmer commented Aug 18, 2016

I migrated from ava and this wasn’t a problem, so maybe there is an answer? Maybe that’s process.exit in Node.js

@cpojer

This comment has been minimized.

Show comment
Hide comment
@cpojer

cpojer Aug 18, 2016

Contributor

We could do that, I guess, but I'm worried it leaves people not hanging when it should and they aren't shutting down their resources properly.

cc @dmitriiabramov what do you think?

Contributor

cpojer commented Aug 18, 2016

We could do that, I guess, but I'm worried it leaves people not hanging when it should and they aren't shutting down their resources properly.

cc @dmitriiabramov what do you think?

@cpojer

This comment has been minimized.

Show comment
Hide comment
@cpojer

cpojer Aug 18, 2016

Contributor

One example: I actually ran into this with Jest myself where we had a long running watcher process that wouldn't terminate Jest itself. If Jest would have killed itself during the test run (heh!) I would have never noticed the issue and I would have shipped a version that would hang when people try to use it.

Contributor

cpojer commented Aug 18, 2016

One example: I actually ran into this with Jest myself where we had a long running watcher process that wouldn't terminate Jest itself. If Jest would have killed itself during the test run (heh!) I would have never noticed the issue and I would have shipped a version that would hang when people try to use it.

@aaronabramov

This comment has been minimized.

Show comment
Hide comment
@aaronabramov

aaronabramov Aug 18, 2016

Member

i'm not sure if it's safe to force kill the process. at the same time, if people want to do some async post processing after the tests are done, they could use after all hook that will wait for it to finish before quitting the process.

the other issue that we might have is cutting the output stream before it finished printing. we had this issue before, when error messages don't have enough time to print before the process exits.

Member

aaronabramov commented Aug 18, 2016

i'm not sure if it's safe to force kill the process. at the same time, if people want to do some async post processing after the tests are done, they could use after all hook that will wait for it to finish before quitting the process.

the other issue that we might have is cutting the output stream before it finished printing. we had this issue before, when error messages don't have enough time to print before the process exits.

@cpojer

This comment has been minimized.

Show comment
Hide comment
@cpojer

cpojer Aug 18, 2016

Contributor

The question is whether we could figure out a way for Jest to say "Looks like some tests aren't cleaning up after themselves. here is what is going on".

Contributor

cpojer commented Aug 18, 2016

The question is whether we could figure out a way for Jest to say "Looks like some tests aren't cleaning up after themselves. here is what is going on".

@calebmer

This comment has been minimized.

Show comment
Hide comment
@calebmer

calebmer Aug 18, 2016

Contributor

An after all hook could help me here, but I haven’t seen such a thing in the documentation (only afterEach) am I missing anything?

As for testing correct cleanups, if you could test if files were completing on time and if they weren’t using a bisect feature to isolate the problem (like in rspec).

Contributor

calebmer commented Aug 18, 2016

An after all hook could help me here, but I haven’t seen such a thing in the documentation (only afterEach) am I missing anything?

As for testing correct cleanups, if you could test if files were completing on time and if they weren’t using a bisect feature to isolate the problem (like in rspec).

@calebmer

This comment has been minimized.

Show comment
Hide comment
@calebmer

calebmer Sep 11, 2016

Contributor

Ok, so after more research this appears to be a problem with Firebase itself, and there is no way to cleanup short of calling process.exit.

Resources:

All of the workarounds involve manually calling process.exit. I’m afraid to do this in a Jest context, is there a recommendation on where to put such a call? My first thought was something like:

afterAll(() => setTimeout(() => process.exit(), 1000))

…to exit one second after all tests finished running to let Jest do its thing, however I’m not sure how this affects watch mode, and if I’m correct Jest does some fancy parallelism stuff which might make this not work as expected. Alternatively, would this be something you need to fix in Jest proper? If this seems like a footgun for a number of people, why not put it into Jest? Or at least a toggle between “warn” mode and “kill” mode.

Contributor

calebmer commented Sep 11, 2016

Ok, so after more research this appears to be a problem with Firebase itself, and there is no way to cleanup short of calling process.exit.

Resources:

All of the workarounds involve manually calling process.exit. I’m afraid to do this in a Jest context, is there a recommendation on where to put such a call? My first thought was something like:

afterAll(() => setTimeout(() => process.exit(), 1000))

…to exit one second after all tests finished running to let Jest do its thing, however I’m not sure how this affects watch mode, and if I’m correct Jest does some fancy parallelism stuff which might make this not work as expected. Alternatively, would this be something you need to fix in Jest proper? If this seems like a footgun for a number of people, why not put it into Jest? Or at least a toggle between “warn” mode and “kill” mode.

@jonathanong

This comment has been minimized.

Show comment
Hide comment
@jonathanong

jonathanong Sep 12, 2016

i'd love a --exit flag or something (it could be a per-file comment or something) that automatically closes the processes when tests complete, similar to mocha. it's a little annoying to manually close every connection in every test file.

jonathanong commented Sep 12, 2016

i'd love a --exit flag or something (it could be a per-file comment or something) that automatically closes the processes when tests complete, similar to mocha. it's a little annoying to manually close every connection in every test file.

@gillchristian

This comment has been minimized.

Show comment
Hide comment
@gillchristian

gillchristian Sep 12, 2016

I'm having the same problem when I run tests in Codeship. It also fails on drone.io.
Locally it works properly though.

EDIT:

  • Jest version: 15.1.1
  • Local:
    • Node: 6.2.2
    • npm: 3.9.5
  • CodeShip:
    • Node: 6.5.0
    • npm: 3.10.3
  • Drone.io
    • Node: 0.10.26
    • npm: 1.4.3

gillchristian commented Sep 12, 2016

I'm having the same problem when I run tests in Codeship. It also fails on drone.io.
Locally it works properly though.

EDIT:

  • Jest version: 15.1.1
  • Local:
    • Node: 6.2.2
    • npm: 3.9.5
  • CodeShip:
    • Node: 6.5.0
    • npm: 3.10.3
  • Drone.io
    • Node: 0.10.26
    • npm: 1.4.3
@cpojer

This comment has been minimized.

Show comment
Hide comment
@cpojer

cpojer Sep 12, 2016

Contributor

It seems to me like Firebase should be fixed.

I have no reservations against adding an option called --forceExitAfterTestRun and it should be easy to add. I think it just requires a change to exit here: https://github.com/facebook/jest/blob/master/packages/jest-cli/src/cli/index.js#L41 if the flag is given regardless of the result.

Contributor

cpojer commented Sep 12, 2016

It seems to me like Firebase should be fixed.

I have no reservations against adding an option called --forceExitAfterTestRun and it should be easy to add. I think it just requires a change to exit here: https://github.com/facebook/jest/blob/master/packages/jest-cli/src/cli/index.js#L41 if the flag is given regardless of the result.

@4ware

This comment has been minimized.

Show comment
Hide comment
@4ware

4ware Sep 12, 2016

Seems to be a race condition of sorts. Sometimes it quits after running all test locally sometimes it doesn't...

4ware commented Sep 12, 2016

Seems to be a race condition of sorts. Sometimes it quits after running all test locally sometimes it doesn't...

@jorilallo

This comment has been minimized.

Show comment
Hide comment
@jorilallo

jorilallo Sep 12, 2016

I'm running this as well after starting to use Jest for my API specs where I'm using real database instead of mocks (sorry 😇 but snapshots are great for this). I yet been able to solve the issue even after adding afterAll hooks to clean up connections which leads me to believe it's some how related to my population of fixtures in setupFiles, not the easiest to debug.

Jasmine seems to have --forceexit option so I would not complain if similar would also land to Jest 🙏

jorilallo commented Sep 12, 2016

I'm running this as well after starting to use Jest for my API specs where I'm using real database instead of mocks (sorry 😇 but snapshots are great for this). I yet been able to solve the issue even after adding afterAll hooks to clean up connections which leads me to believe it's some how related to my population of fixtures in setupFiles, not the easiest to debug.

Jasmine seems to have --forceexit option so I would not complain if similar would also land to Jest 🙏

@jonathanong

This comment has been minimized.

Show comment
Hide comment
@jonathanong

jonathanong Sep 12, 2016

another issue - if a test fails, then afterAll() isn't called, so nothing is cleaned up and nothing closes. i think --bail will fix this but i haven't tried that yet

jonathanong commented Sep 12, 2016

another issue - if a test fails, then afterAll() isn't called, so nothing is cleaned up and nothing closes. i think --bail will fix this but i haven't tried that yet

@cpojer

This comment has been minimized.

Show comment
Hide comment
@cpojer

cpojer Sep 15, 2016

Contributor

If anyone would like to send a PR, this is something that we could use some help with and I outlined details in my previous comment :)

Contributor

cpojer commented Sep 15, 2016

If anyone would like to send a PR, this is something that we could use some help with and I outlined details in my previous comment :)

@gillchristian

This comment has been minimized.

Show comment
Hide comment
@gillchristian

gillchristian Sep 15, 2016

I'll give it a shot if I get some time over the weekend. If someone wants to do it before that it'd cool 😄

gillchristian commented Sep 15, 2016

I'll give it a shot if I get some time over the weekend. If someone wants to do it before that it'd cool 😄

yutin1987 added a commit to yutin1987/jest that referenced this issue Oct 3, 2016

feat(jest-cli): add forceExitAfterTestRun avg
After run all tests that force exit when forceExitAfterTestRun is true

facebook#1456
@cpojer

This comment has been minimized.

Show comment
Hide comment
@cpojer

cpojer Oct 3, 2016

Contributor

Closing in favor of the PR that was just opened. We'll continue the discussion there.

Contributor

cpojer commented Oct 3, 2016

Closing in favor of the PR that was just opened. We'll continue the discussion there.

@cpojer cpojer closed this Oct 3, 2016

yutin1987 added a commit to yutin1987/jest that referenced this issue Oct 3, 2016

feat(jest-cli): add forceExitAfterTestRun avg
After run all tests that force exit when forceExitAfterTestRun is true

facebook#1456

yutin1987 added a commit to yutin1987/jest that referenced this issue Oct 3, 2016

feat(jest-cli): add forceExit avg on cli
After run all tests that force exit when forceExit is true

facebook#1456

pastuxso added a commit to pastuxso/pokedom that referenced this issue Oct 5, 2016

Add patched jest-cli dependency
Add patchet jest-cli with the command line param --forceExit to solve
problems when jest process doesn’t quit after last test completes.

More info:

facebook/jest#1456

cpojer added a commit that referenced this issue Oct 17, 2016

RDY: feat(jest-cli): add forceExitAfterTestRun avg (Duplicated of PR #…
…1847) (#1870)

* feat(jest-cli): add forceExit avg on cli

After run all tests that force exit when forceExit is true

#1456

* Fix typecheck & linter offences

* Improve null check expression

* Update index.js

nickcolley added a commit to alphagov/govuk-frontend that referenced this issue Jan 24, 2018

Ensure app tests exit correctly
See facebook/jest#1456 for discussion around this problem
@samuela

This comment has been minimized.

Show comment
Hide comment
@samuela

samuela Apr 6, 2018

In my case this ended up being a Firebase issue. Using

afterAll(() => {
  firebaseApp.database().goOffline();
  firebaseApp.delete();
});

seems to do the trick. I've found that both lines are actually necessary and that you need to use the same firebaseApp that you originally get from .initializeApp().

samuela commented Apr 6, 2018

In my case this ended up being a Firebase issue. Using

afterAll(() => {
  firebaseApp.database().goOffline();
  firebaseApp.delete();
});

seems to do the trick. I've found that both lines are actually necessary and that you need to use the same firebaseApp that you originally get from .initializeApp().

DanielMSchmidt added a commit to mesosphere/mockserver that referenced this issue Apr 18, 2018

ci(tooling): force exit of jest
Seems to be a known problem with jest on Jenkins:
facebook/jest#1456 (comment)

DanielMSchmidt added a commit to mesosphere/mockserver that referenced this issue Apr 18, 2018

ci(tooling): force exit of jest
Seems to be a known problem with jest on Jenkins:
facebook/jest#1456 (comment)

DanielMSchmidt added a commit to mesosphere/mockserver that referenced this issue Apr 18, 2018

ci(tooling): force exit of jest
Seems to be a known problem with jest on Jenkins:
facebook/jest#1456 (comment)
@henrygold7

This comment has been minimized.

Show comment
Hide comment
@henrygold7

henrygold7 Jun 7, 2018

Is there any way to solve this without forceExit?

henrygold7 commented Jun 7, 2018

Is there any way to solve this without forceExit?

@SimenB

This comment has been minimized.

Show comment
Hide comment
@SimenB

SimenB Jun 7, 2018

Collaborator

Jest 23 includes a flag called --detectOpenHandles which should point to the source of why Jest is unable to exit

Collaborator

SimenB commented Jun 7, 2018

Jest 23 includes a flag called --detectOpenHandles which should point to the source of why Jest is unable to exit

@elkhan

This comment has been minimized.

Show comment
Hide comment
@elkhan

elkhan Jun 8, 2018

--detectOpenHandles returns mongoose.connect and mongoose.model. Trying to mongoose.disconnect in afterAll raises mongo error Topology destroyed.

screenshot 2018-06-08 11 14 51

screenshot 2018-06-08 11 14 29

elkhan commented Jun 8, 2018

--detectOpenHandles returns mongoose.connect and mongoose.model. Trying to mongoose.disconnect in afterAll raises mongo error Topology destroyed.

screenshot 2018-06-08 11 14 51

screenshot 2018-06-08 11 14 29

@sibelius

This comment has been minimized.

Show comment
Hide comment
@sibelius

sibelius Jul 27, 2018

@elkhan have u figure it out how to solve mongoose problems?

sibelius commented Jul 27, 2018

@elkhan have u figure it out how to solve mongoose problems?

@motss

This comment has been minimized.

Show comment
Hide comment
@motss

motss Aug 20, 2018

After adding --detectOpenHandles, not only does Jest complete my tests and also not showing anything that actually blocks Jest which is weird. Looks like a bug.

motss commented Aug 20, 2018

After adding --detectOpenHandles, not only does Jest complete my tests and also not showing anything that actually blocks Jest which is weird. Looks like a bug.

@voidcenter

This comment has been minimized.

Show comment
Hide comment
@voidcenter

voidcenter Aug 20, 2018

For me, --forceExit solves the problem, at the same time I use --detectOpenHandles but it detects nothing (both locally and on CircleCI). I'm also running with --runInBand.

voidcenter commented Aug 20, 2018

For me, --forceExit solves the problem, at the same time I use --detectOpenHandles but it detects nothing (both locally and on CircleCI). I'm also running with --runInBand.

@cainarm

This comment has been minimized.

Show comment
Hide comment
@cainarm

cainarm Aug 29, 2018

For me, removing --runInBand solved it.

cainarm commented Aug 29, 2018

For me, removing --runInBand solved it.

@afloyd

This comment has been minimized.

Show comment
Hide comment
@afloyd

afloyd Sep 13, 2018

--forceExit solves the problem for me as well when using shippable ... Tried --detectOpenHandles but didn't give any results and still just caused the build to hang

afloyd commented Sep 13, 2018

--forceExit solves the problem for me as well when using shippable ... Tried --detectOpenHandles but didn't give any results and still just caused the build to hang

@seanlindo

This comment has been minimized.

Show comment
Hide comment
@seanlindo

seanlindo Sep 18, 2018

Adding --detectOpenHandles fixes the issue, which is bizarre.

Node: v8.12.0
Jest: v23.6.0

seanlindo commented Sep 18, 2018

Adding --detectOpenHandles fixes the issue, which is bizarre.

Node: v8.12.0
Jest: v23.6.0

mrfelton added a commit to mrfelton/zap-desktop that referenced this issue Sep 19, 2018

test(jest): run jest with --forceExit flag
Jest is sometimes unable to detect when tests have completed which can
result in tests hanging indefinitely, which breaks our CI builds on
Appveyor.

This is a know issue in jest and they added a `forceExit` in order to
help users facing this issue.

See facebook/jest#1456

@mrfelton mrfelton referenced this issue Sep 19, 2018

Merged

test(jest): run jest with --forceExit flag #784

5 of 6 tasks complete
@carloscheddar

This comment has been minimized.

Show comment
Hide comment
@carloscheddar

carloscheddar Sep 19, 2018

Adding --detectOpenHandles or --forceExit doesn't fix the issue for me when running on Codeship.

jest --ci --verbose --forceExit --detectOpenHandle

Node: v8.12.0
Jest: v23.6.0

carloscheddar commented Sep 19, 2018

Adding --detectOpenHandles or --forceExit doesn't fix the issue for me when running on Codeship.

jest --ci --verbose --forceExit --detectOpenHandle

Node: v8.12.0
Jest: v23.6.0

@lfades

This comment has been minimized.

Show comment
Hide comment
@lfades

lfades Sep 19, 2018

@sibelius a way of avoiding this issue is by muting the init function of the model

const mongoose = require('mongoose');

mongoose.Model.init = () => {};

This will stop Jest from complaining about the models, although indexes will not be created

lfades commented Sep 19, 2018

@sibelius a way of avoiding this issue is by muting the init function of the model

const mongoose = require('mongoose');

mongoose.Model.init = () => {};

This will stop Jest from complaining about the models, although indexes will not be created

@msal4

This comment has been minimized.

Show comment
Hide comment
@msal4

msal4 Sep 21, 2018

db.collection("test-collection").add({
    title: 'post title',
    content: 'This is the test post content.',
    date: new Date(),
})
    .then(docRef => {
        console.log('Document written with ID: ', docRef);
    })
    .catch(error => {
        console.error('Error adding document: ', error);
    });

jest --forceExit --detectOpenHandle the tests are passed, but the code in.then or .catch does not run!!
any ideas?

msal4 commented Sep 21, 2018

db.collection("test-collection").add({
    title: 'post title',
    content: 'This is the test post content.',
    date: new Date(),
})
    .then(docRef => {
        console.log('Document written with ID: ', docRef);
    })
    .catch(error => {
        console.error('Error adding document: ', error);
    });

jest --forceExit --detectOpenHandle the tests are passed, but the code in.then or .catch does not run!!
any ideas?

@dmayerdesign

This comment has been minimized.

Show comment
Hide comment
@dmayerdesign

dmayerdesign Sep 25, 2018

@alexpchin Here's how I solved it:

    beforeAll(async (done) => {
        dbConnection = await mongoose.connect(...)
        done()
    })

    afterAll(async (done) => {
        await dbConnection.close()
        dbConnection.on('disconnected', done)
    })

dmayerdesign commented Sep 25, 2018

@alexpchin Here's how I solved it:

    beforeAll(async (done) => {
        dbConnection = await mongoose.connect(...)
        done()
    })

    afterAll(async (done) => {
        await dbConnection.close()
        dbConnection.on('disconnected', done)
    })
@henrikra

This comment has been minimized.

Show comment
Hide comment
@henrikra

henrikra Sep 25, 2018

With NestJs I had to add

afterAll(() => {
  app.close();
});

henrikra commented Sep 25, 2018

With NestJs I had to add

afterAll(() => {
  app.close();
});
@carloscheddar

This comment has been minimized.

Show comment
Hide comment
@carloscheddar

carloscheddar Sep 25, 2018

We found that this issue was caused by the jest process running out of memory. Adding --maxWorkers=10 fixed the issue for us.

carloscheddar commented Sep 25, 2018

We found that this issue was caused by the jest process running out of memory. Adding --maxWorkers=10 fixed the issue for us.

@srfrnk

This comment has been minimized.

Show comment
Hide comment
@srfrnk

srfrnk Sep 28, 2018

I'm adding this cause maybe someone wondering into this issue might be having the reason for this as I had.
I was using Jest within Travis to test a NodeJS app and travis kept hanging until timeout directly after Jest. Appears Jest was not closing down.
After many tryes I discovered the reason was using jest with JSDom.
I had the following line in my jest.config.js file:

  'testURL': 'http://localhost/',

Which caused JSDom to load and supposedly not closing all resources gracefully and keeping Jest alive.

I solved it by removing the line - however Jest will then fail with the following error see this:

SecurityError: localStorage is not available for opaque origins

To solve it I added the following to jest.config.js:

  'testEnvironment': 'node',

Hope that helps anyone.I'm adding this cause maybe someone wondering into this issue might be having the reason for this as I had.
I was using Jest within Travis to test a NodeJS app and travis kept hanging until timeout directly after Jest. Appears Jest was not closing down.
After many tryes I discovered the reason was using jest with JSDom.
I had the following line in my jest.config.js file:

  'testURL': 'http://localhost/',

Which caused JSDom to load and supposedly not closing all resources gracefully and keeping Jest alive.

I solved it by removing the line - however Jest will then fail with the following error see this:

SecurityError: localStorage is not available for opaque origins

To solve it I added the following to jest.config.js:

  'testEnvironment': 'node',

Hope that helps anyone.

srfrnk commented Sep 28, 2018

I'm adding this cause maybe someone wondering into this issue might be having the reason for this as I had.
I was using Jest within Travis to test a NodeJS app and travis kept hanging until timeout directly after Jest. Appears Jest was not closing down.
After many tryes I discovered the reason was using jest with JSDom.
I had the following line in my jest.config.js file:

  'testURL': 'http://localhost/',

Which caused JSDom to load and supposedly not closing all resources gracefully and keeping Jest alive.

I solved it by removing the line - however Jest will then fail with the following error see this:

SecurityError: localStorage is not available for opaque origins

To solve it I added the following to jest.config.js:

  'testEnvironment': 'node',

Hope that helps anyone.I'm adding this cause maybe someone wondering into this issue might be having the reason for this as I had.
I was using Jest within Travis to test a NodeJS app and travis kept hanging until timeout directly after Jest. Appears Jest was not closing down.
After many tryes I discovered the reason was using jest with JSDom.
I had the following line in my jest.config.js file:

  'testURL': 'http://localhost/',

Which caused JSDom to load and supposedly not closing all resources gracefully and keeping Jest alive.

I solved it by removing the line - however Jest will then fail with the following error see this:

SecurityError: localStorage is not available for opaque origins

To solve it I added the following to jest.config.js:

  'testEnvironment': 'node',

Hope that helps anyone.

mrfelton pushed a commit to mrfelton/zap-desktop that referenced this issue Sep 30, 2018

Tom Kirkpatrick
ci(jest): set maxWorkers to 2
Jest process doesn’t quit after last test completes. This can cause our
tests to fail sometimes, particularly on on Appveyor.

As an attempt to get past this previously we had set `--forceExit` in
our jest cli options, but this doesn't always work either.

Further research suggests that setting ``--maxWorkers=2` could resolve
the issue.

See
 - facebook/jest#1456 (comment)
 - https://github.com/facebook/jest/blob/master/docs/Troubleshooting.md

Fix #774, Fix #773

@mrfelton mrfelton referenced this issue Sep 30, 2018

Merged

ci(jest): set maxWorkers to 2 #827

6 of 6 tasks complete
@qopqopqop

This comment has been minimized.

Show comment
Hide comment
@qopqopqop

qopqopqop Oct 7, 2018

--forceExit --detectOpenHandles --maxWorkers=10

did it for us

node: 8.11.3
jest 23.6.0

qopqopqop commented Oct 7, 2018

--forceExit --detectOpenHandles --maxWorkers=10

did it for us

node: 8.11.3
jest 23.6.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment