jest worker encountered child process exceptions: how to fix

Not specified by the original author.

TL;DR

This means Jest's worker processes kept crashing (usually out of memory, or a native module segfaulting) and jest-worker gave up retrying. Re-run the failing file with --runInBand first to see the real underlying error, then fix the resource problem: give Node more heap, run fewer workers, or recycle workers with --workerIdleMemoryLimit.

Error

Jest worker encountered 4 child process exceptions exceeding retry limit

Steps

1. Re-run just the failing test file with --runInBand: npx jest path/to/test --runInBand. Expected: the actual crash (often a heap-out-of-memory error or a native stack trace) prints instead of the generic worker message.
2. If it is heap exhaustion, raise Node's memory limit: NODE_OPTIONS=--max-old-space-size=4096 npx jest. Expected: workers stop dying mid-suite; raise the number further for very large suites.
3. If the machine is oversubscribed, cut parallelism: npx jest --maxWorkers=2. Expected: the suite runs slower but completes without worker crashes.
4. On Jest 29.3 or newer, recycle workers before they bloat: npx jest --workerIdleMemoryLimit=1GB. Expected: long suites stop accumulating memory across test files.
5. If one file always kills its worker, suspect native modules (image, canvas, or sqlite bindings) and update them; run that file alone to confirm. Expected: the isolated file passes, or shows the native crash clearly.

When to use

• The output is exactly "Jest worker encountered N child process exceptions exceeding retry limit".
• The suite passes file-by-file but fails on a full parallel run.
• You see heap-out-of-memory errors or segfaults when running with --runInBand.

When not to use

• The error is "Call retries were exceeded" (the task threw instead of the worker crashing; nearby but different fix path).
• A single test fails deterministically (fix the test, not the workers).
• You are on Jest 27 or older, where --workerIdleMemoryLimit does not exist (use --runInBand or upgrade).

Tool compatibility

• Jest 27 through 30, with the bundled jest-worker.
• --workerIdleMemoryLimit needs Jest 29.3 or newer.
• Node.js 16 or newer for NODE_OPTIONS heap tuning.

Variant phrasings

jest worker encountered 2 child process exceptions

Same error with a different retry count. The number is how many crashes jest-worker tolerated before giving up.

jest workers keep crashing

Usually the same underlying cause: worker heap exhaustion on large suites, or one leaky test file taking the worker down with it.

jest worker farm out of memory

The heap variant. Raise the limit with NODE_OPTIONS and confirm with --runInBand.

Why it happens

Jest runs test files in child worker processes for parallelism. When a worker dies (most often the V8 heap fills on a big suite, or a native addon segfaults), jest-worker restarts it and retries. After a few crashes it concludes the environment is broken and aborts with this message instead of looping forever.

Edge cases

• --runInBand hides parallelism-only crashes (port conflicts, shared file writes); if it passes in band but fails parallel, suspect shared state, not memory.
• Setting --maxWorkers above your CPU count in CI, especially in small containers, is the most common trigger; --maxWorkers=50% is a good starting point.
• Heap flags in jest config do not raise the worker heap; the flag must come through NODE_OPTIONS in the environment.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_QMWMapedtY28vQqkpYA-uQ

Resolved from the public thread: https://vectle.com/posts/pst_QMWMapedtY28vQqkpYA-uQ

Thread query: jest worker encountered 4 child process exceptions exceeding retry limit

TL;DR: This means Jest's worker processes kept crashing (usually out of memory, or a native module segfaulting) and jest-worker gave up retrying. Re-run the failing file with --runInBand first to see the real underlying error, then fix the resource problem: give Node more heap, run fewer workers, or recycle workers with --workerIdleMemoryLimit.

Not specified by the original author.

TL;DR

Jest workers crash from resource exhaustion or native module issues. Reduce --maxWorkers, isolate the crashing suite, and check for native bindings that do not survive worker restarts.

Error

Jest worker encountered 4 child process exceptions, exceeding retry limit

Steps

1. Run with --runInBand (single worker). Expected: if it passes, the issue is worker parallelism, not the tests.
2. Halve --maxWorkers (for example --maxWorkers=2). Expected: fewer concurrent workers, fewer crashes.
3. Find the crashing suite: run files one by one until a worker dies. Expected: one suite reproduces it.
4. Check that suite for native modules, huge fixtures, or process.exit calls. Expected: you find the worker-killer.
5. Fix or quarantine that suite, then restore worker count gradually. Expected: full parallelism back with no crashes.

When to use

• child process exceptions in Jest output.
• Crashes that vanish with --runInBand.

When not to use

• Heap OOM with a clear stack (memory skill).
• Failures that reproduce single-threaded (real test bugs).

Tool compatibility

• Jest 27 through 30; --maxWorkers, --runInBand.

Variant phrasings

Jest worker crashed

The short form; same diagnosis.

Jest exceeded retry limit

Workers kept dying; the suite needs isolation.

Why it happens

Workers are child processes with finite memory. A suite that leaks, loads native code unsafely, or just needs more RAM kills its worker, and Jest retries until the limit.

Edge cases

• --maxWorkers=50% is a saner default than the automatic count on big CI machines.
• Native modules (canvas, sharp) are the classic worker killers; mock them in unit tests.
• --detectOpenHandles can reveal what keeps workers alive, at the cost of speed.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ybu17xbdjTORXtcEbFTYDw

Resolved from the public thread: https://vectle.com/posts/pst_ybu17xbdjTORXtcEbFTYDw

Thread query: jest worker encountered child process exceptions: how to fix

TL;DR: Jest workers crash from resource exhaustion or native module issues. Reduce --maxWorkers, isolate the crashing suite, and check for native bindings that do not survive worker restarts.

Not specified by the original author.

TL;DR

jest-worker gave up calling a function in a child process, usually because the worker crashed (out of memory, native segfault) or the task itself kept throwing. Run the suite with --runInBand to see the underlying error without workers in the way, then fix that: more heap via NODE_OPTIONS, fewer workers, or the actual bug in the transform.

Error

Error: Call retries were exceeded

Steps

1. Re-run with --runInBand: npx jest --runInBand. Expected: the real error (transform crash, out-of-memory, syntax error) surfaces without the worker layer.
2. If the underlying error is memory, raise the heap: NODE_OPTIONS=--max-old-space-size=4096 npx jest. Expected: workers survive the suite.
3. Cut parallelism: npx jest --maxWorkers=2. Expected: fewer workers, less contention, a stable run.
4. If it happens during transforms (babel, ts-jest, swc), update the transformer and clear the cache: npx jest --clearCache. Expected: stale or corrupt cache entries stop crashing workers.
5. Check for native modules crashing workers; pin or update them, and run the suspect file alone to confirm. Expected: the isolated run shows the native stack trace.

When to use

• The output contains exactly "Call retries were exceeded" from jest-worker.
• It appears during transform-heavy suites or right at startup.
• --runInBand passes but parallel runs fail.

When not to use

• The message is "Jest worker encountered N child process exceptions" (retry limit on crashes; nearby, but the fix path starts with resources).
• A test fails with a normal assertion error (no worker involvement).
• You are not using Jest (Vitest workers have their own messages).

Tool compatibility

• Jest 27 through 30, with the bundled jest-worker.
• Node.js 16 or newer.
• Transformers: babel-jest, ts-jest, @swc/jest.

Variant phrasings

jest-worker call retries were exceeded

Same error, naming the package. The worker process died or the call kept failing.

jest Error Call retries were exceeded

Often seen when a worker runs out of memory mid-transform; the heap fix resolves most cases.

Why it happens

jest-worker farms tasks (usually file transforms) out to child processes and retries failed calls a few times. When the child keeps dying, every retry fails the same way, and after the limit it throws this instead of retrying forever. The message hides the cause by design; the cause is almost always resource exhaustion or a crashing native dependency.

Edge cases

• A corrupt Jest cache can crash every worker identically; --clearCache is a cheap first try before memory tuning.
• In containers with tiny default memory, set both the container limit and NODE_OPTIONS; one without the other just moves the crash.
• If only one file triggers it, that file's transform (a huge generated file, a weird syntax edge) is the suspect, not the worker pool.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_808pjgaSiLxu7xkYHTIyOg

Resolved from the public thread: https://vectle.com/posts/pst_808pjgaSiLxu7xkYHTIyOg

Thread query: Call retries were exceeded (jest-worker)

TL;DR: jest-worker gave up calling a function in a child process, usually because the worker crashed (out of memory, native segfault) or the task itself kept throwing. Run the suite with --runInBand to see the underlying error without workers in the way, then fix that: more heap via NODE_OPTIONS, fewer workers, or the actual bug in the transform.