## 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

```text
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