Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

218
Views
How can I disable Jest's unhandledRejection detection

I'm writing a test and simulates a failure API response. The library that acts as a client for that API generates an uncaught rejection in this case.

This is 100% a bug in the library and we're on the process of deprecating that library, but migrating away from it will take some more weeks and I need my test passing today.

Unfortunately, Jest does not offer a functionality to disable this behavior. jest-circus adds its own handlers and fails the test. This happens in jest-circus/src/globalErrorHandlers.ts.

I've tried commenting-out the body of uncaught in that file and that does indeed "fix" my problem, which confirms these handlers are what I'm looking for.

/**
 * Copyright (c) Facebook, Inc. and its affiliates. All Rights Reserved.
 *
 * This source code is licensed under the MIT license found in the
 * LICENSE file in the root directory of this source tree.
 */
const uncaught = error => {
  // commenting-out this call to dispatchSync "fixes" the issue
  // (0, _state.dispatchSync)({
  //   error,
  //   name: 'error'
  // });
};

My next thought was to do a process.removeAllListeners('unhandledRejection'); in my test (roughly speaking), but that doesn't work, even when running with --runInBand.

After some debugging, I found out that:

  • process.pid in my test and parentProcess.pid in jest-circus are equal, but
  • process.listenerCount('unhandledRejection') and parentProcess.listenerCount('unhandledRejection') are not (zero and one, respectively), and
  • process.mainModule is undefined in my test but parentProcess.mainModule is defined in jest-circus (filename: .../jest/bin/jest.js).

That confused me completely. They seem to be different processes, yet share the same pid.

To debug further, I did a

  // in my test
  beforeAll(() => {
    process.emitWarning('emitted warning process from my test. count: ' + process.listenerCount('unhandledRejection'));
  });

  // in globalErrorHandlers.js
  parentProcess.on('warning', warning => {
    console.log('parentProcess warning', parentProcess.listenerCount('unhandledRejection'), ' --- ', warning);
  });

And this outputs parentProcess warning 1 --- Warning: emitted warning process from my test. count: 0 to the console, which I guess would indicate they are the same process (which makes sense), yet somehow the listenerCount differs!

As a side note, jest-circus' injectGlobalErrorHandlers always runs before my test code, even global-space code. restoreGlobalErrorHandlers always runs after.

about 4 years ago · Juan Pablo Isaza
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!