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.

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