Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

231
Vistas
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
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda