The unhandledRejection handler is not testable anymore.

[despairblue]

Do you want to request a feature or report a bug?

Regression

What is the current behavior?

Current versions of jest don't allow testing unhandledRejections. The following test will never succeed:

const foo = require(".");

describe("foo", () => {
  test("bar", done => {
    process.removeAllListeners("unhandledRejection");
    process.on("unhandledRejection", function(error) {
      process.removeAllListeners("unhandledRejection");
      expect(error).toBeInstanceOf(Error);
      done();
    });

    foo();
  });
});

If the current behavior is a bug, please provide the steps to reproduce and
either a repl.it demo through https://repl.it/languages/jest or a minimal
repository on GitHub that we can yarn install and yarn test.

I made a repository with two commits with different jest versions showing that it works with an older version but not anymore with the current one. The README describes the repro steps in detail.

What is the expected behavior?

It should be possible to test unhandledRejection and uncaughtExceptions.

Btw I'm well aware that this is a case of https://xkcd.com/1172/ and that we could refactor the code to not rely on unhandledRejection for error reporting of unknown errors that happen. But it's actually really convenient to use the unhandledRejection handler to report to rollbar and shutdown the process orderly.

Please provide your exact Jest configuration and mention your Jest, node,
yarn/npm version and operating system.

OS: Mac 10.12.6
Node: v8.9.4
Yarn: 1.3.2

[JeffBaumgardt]

Not to dredge up the dead but I have a similar issue with testing unhandledrejection. Consider

window.addEventListener('unhandledrejection', event => this.onUnhandledRejection(event), {
    passive: true,
})

This code should take any unhandled promise rejection and work with it.

It works in browser but I think jsdom or jest doesn't support it. For now I have the line ignored but it would be nice to have.

OS: Windows 10
Node: 10.7.0
NPM: 6.0.0

[LukasBombach]

Confirming the bug with a simple example:

test('catches unhandled rejections', async () => {
  const errorHandler = jest.fn();
  const error = new Error('mock error');
  process.on('unhandledRejection', err => errorHandler(err))
  await Promise.reject(error);
  expect(errorHandler).toHaveBeenCalledWith(error);
});

will give you this

● catches unhandled rejections

mock error

  13 |
  14 | test('catches unhandled rejections', async () => {
> 15 |   const error = new Error('mock error');
     |                 ^
  16 |   const errorHandler = jest.fn();
  17 |   process.on('unhandledRejection', err => errorHandler(err))
  18 |   await Promise.reject(error);

  at Object.<anonymous>.test (test/bin.test.js:15:17)

OS: macOs 10.13.6
Node: v8.11.4 (LTS)
Yarn: 1.9.4

I also took this to StackOverflow: https://stackoverflow.com/questions/52493145/how-to-test-a-unhandledrejection-uncaughtexception-handler-with-jest

[kschat]

Has anyone found a workaround for this issue?

[wearhere]

Confirmed that this breaks testing functions that throw uncaught exceptions, too: https://repl.it/repls/FreeFluffyAdministration

[sb-junhyeong]

This should be resolved because unhandledPromiseRejection might make random subsequent test fail.

[deepal]

Any update on this issue yet?

[jrnail23]

Same problem here... trying to test my error handling (logging, Sentry reporting). It works fine in my other app that uses mocha for its tests, but Jest just won't let me do it.

[sadokmtir]

+1

[curiosity26]

+1

[p10ns11y]

+1

[snayan]

+1

[pspi]

Any updates on this? This would be needed to test error cases where error gets thrown after user response has already been sent.

[Jack-Works]

Yes, I want to ensure there is a unhandledPromiseRejection and I found I can't do this in Jest.

[tomapaunovic]

I can confirm this issue still happens for 'uncaughtException' as well. Currently, I don't have any workaround, other than rewrite production code to emit errors instead of throwing them, and then catch with this.on('error')

[mmarchini]

This happens because jest mocks the global process object, which prevents access to the real unhandledRejection event. I couldn't find any way to circumvent the mock or register an unhandledRejection event for a single test.

[agarnoth]

This prevents making the test fail when there is an unhandled promise in the code. It is a problem because developers are not aware there is something to fix since the test is marked successful. If there is only one test we could ask the dev to check the "UnhandledPromiseRejectionWarning" is not present in the logs before they merge, the problem is there are many tests and those warnings might be easily unseen as long as the tests are green. We then end up with many unhandled promises in the tests that might disrupt the execution of tests in our CI, and also many unhandled promises unfixed in the code, it is really bad.

After some tests, it is not possible to listen to the process events because it is not the real one (why?), we can't exploit its stdout either, the stdout of the test can't be piped :(. Even if we could exploit stdout, what we need is to fail the test to prevent the merge, so it should be done in the jest run. I haven't found any workaround. This was possible to fix in jest 24 by listening to the process "unhandledRejection" event but not possible in jest 26 because process is not the real one.

Please help?

[nesk]

This is a real issue, we can't always catch exceptions because some of them might be thrown within setTimeout() or setInterval() callbacks:

setTimeout(() => { throw new Error(); }, 100);

This code above is, currently, untestable. Is there any maintainer who can help? Or at least help the community to provide a PR fixing this?

[nesk]

I was able to fix this by creating a bootstrap file which runs right before Jest and stores the original process instance in a global variable! I've written a blog post about it: https://johann.pardanaud.com/blog/how-to-assert-unhandled-rejection-and-uncaught-exception-with-jest/

Once the bootstrap is setup, you will be able to write your tests just like this:

test('promise is rejected', async () => {
  const unhandledRejectionPromise = new Promise((resolve) => {
    process._original().on('unhandledRejection', resolve)
  })

  Promise.reject('test')

  await expect(unhandledRejectionPromise).resolves.toBe('test')
})

[piranna]

Any update? This regression has been open for more than three years... Jest 27 in Node.js 16 is dying because UnhandledPromiseRejection is not captured, while it should be done and mark the test as failed, showing the original error, not the exception about the error not being captured.

[icecream17]

I ran into this problem too

Setup file:
https://github.com/icecream17/solver/blob/7acc0aaae5bee787cc65670c17b21c846b360ba3/src/setupTests.ts#L1-L14

Github action:

https://github.com/icecream17/solver/runs/2720074223?check_suite_focus=true

[stagas]

Half a workaround is to put this inside jest.config.js, since it's being read before the process object is replaced by the (broken) mock:

const actualProcess = process
process.actual = () => actualProcess

(note it has to be a getter function as shown and not a property as it will not work for some weird reason related to the mock proxy)

Then in the test:

declare const process: any
beforeAll(() => process.actual().removeAllListeners('uncaughtException'))

...

  it('errors', () => {
    queueMicrotask(() => {
      throw new Error('some error')
    })

    return new Promise(resolve =>
      process.actual().once('uncaughtException', (error: Error) => {
        expect(error.message).toContain('some error')
        resolve(null)
      })
    )
  })

Same process for unhandledRejection i suppose.

If you want to be really nitpicky you'd want to reintroduce the listeners you removed, such as described here, which was the original idea for this trick - except we don't need to create new scripts.

[github-actions]

This issue is stale because it has been open for 1 year with no activity. Remove stale label or comment or this will be closed in 30 days.

[grossbart]

GitHub bot wants to close this, but it is as relevant as ever. Adding workarounds is ok-ish in our own codebase, but when contributing to other repos this is a bit much and a proper solution would be appreciated.

[antitoxic]

Is there an non-workaround/official/recommended approach for testing uncaught rejections or errors? Tagging latest contributors: @mrazauskas @SimenB ?

[Voltra]

Up

[liuxingbaoyu]

#14315
Does this PR fix it?

[zmagyar]

#14315 Does this PR fix it?

Tested with v30.0.0-alpha.6 but it doesn't seem to solve the problem.

[yc-kanyun]

Half a workaround is to put this inside jest.config.js, since it's being read before the process object is replaced by the (broken) mock:

const actualProcess = process
process.actual = () => actualProcess
(note it has to be a getter function as shown and not a property as it will not work for some weird reason related to the mock proxy)

Then in the test:

declare const process: any
beforeAll(() => process.actual().removeAllListeners('uncaughtException'))

...

it('errors', () => {
queueMicrotask(() => {
throw new Error('some error')
})

return new Promise(resolve =>
  process.actual().once('uncaughtException', (error: Error) => {
    expect(error.message).toContain('some error')
    resolve(null)
  })
)

})
Same process for unhandledRejection i suppose.

If you want to be really nitpicky you'd want to reintroduce the listeners you removed, such as described here, which was the original idea for this trick - except we don't need to create new scripts.

it works for me

here is an code sandbox

https://codesandbox.io/p/devbox/z9qdp4?migrateFrom=zzjfzz