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

[Bug]: uncaught async error crashes jest --watch #13996

Closed
benjaminjkraft opened this issue Mar 9, 2023 · 5 comments · Fixed by #14059
Closed

[Bug]: uncaught async error crashes jest --watch #13996

benjaminjkraft opened this issue Mar 9, 2023 · 5 comments · Fixed by #14059

Comments

@benjaminjkraft
Copy link
Contributor

benjaminjkraft commented Mar 9, 2023

Version

29.5.0

Steps to reproduce

  1. Write a test which throws an error after completing.
  2. Run jest --watch <test file>.
  3. After the error is thrown, Jest crashes rather than reporting it with the usual "error after test finished".

Repro repo here, run npx jest --watchAll and wait 1s.

Expected behavior

I expected Jest to report the failure, but continue in watch-mode.

Actual behavior

Jest crashes and doesn't continue to watch.

Additional context

Seems to only happen when running just one test file, so I'm guessing it has to do with tests that run in-band instead of in a worker?

Environment

System:
  OS: macOS 13.2.1
  CPU: (10) x64 Apple M1 Max
Binaries:
  Node: 16.17.1 - /nix/store/fyaisfdhkviz6sb628qxlmy5wcasqfhq-nodejs-16.17.1/bin/node
  npm: 8.12.1 - ~/.local/bin/npm
npmPackages:
  jest: ^29.5.0 => 29.5.0
@AppSphere
Copy link

I am facing a similar issue where the Jest Crashes with an error
Error: Error: spawnSync /bin/sh ENOBUFS
On Local it just works fine. This happens in Github Actions during PR run.

@mrazauskas
Copy link
Contributor

@benjaminjkraft This is expected behaviour. You should look through the Testing Asynchronous Code guide.

The test case in your reproduction throws when the test run is already finished. Jest should crash, because something fatal happened. That test simply should not pass. You should await the promises, mock timers, catch errors inside a test. If something throws outside of any test, this is considered fatal.

@benjaminjkraft
Copy link
Contributor Author

I understand that I'm supposed to await promises. I nonetheless find this frustrating because it means watch mode is useless if I am debugging why the test is not correctly awaiting its promises! And I find it a bit confusing because if I run multiple tests (and thus, I'm guessing, multiple workers) in watch-mode the test will actually pass (with a warning about open handles). I guess what you are saying means the fact that it doesn't crash in that case is a bug?

@mrazauskas
Copy link
Contributor

Ah.. Looks like I misunderstood the problem, open handles is different case.

I copied you the test case from your repo into larger code base. Jest crashes with --watch, but show the "has failed to exit gracefully" error with --watchAll. You are right, this is because of workers being involved with --watchAll and more test running at once.

This can be solved by tweaking shouldRunInBand() logic in the below lines:

https://github.com/facebook/jest/blob/470d72ee74e50291bf8593954f24eb75b5621351/packages/jest-core/src/testSchedulerHelper.ts#L45-L47

Thanks for more details. I think the behaviour should be more predictable.

benjaminjkraft added a commit to benjaminjkraft/jest that referenced this issue Apr 6, 2023
The comment here already said one good reason to do this; another is
that if the test hard-crashes (e.g. an async error after it completes)
then using workers allows us to still watch for changes (perhaps to fix
that crash). So now we just always use workers in watch mode; this
probably worsens startup time slightly but for watch mode that's
hopefully not as much of a problem.

Fixes jestjs#13996.
@github-actions
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 16, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants