What causes "Internal error in a worker process." in nodejs/node?

Read the lines immediately above this error in the log: logging.exception already printed the real worker traceback — fix the underlying cause there.

nodejs/node · error · Exception

Internal error in a worker process.

Error message

Internal error in a worker process.

What it means

Raised at the end of TestRunner pool execution in deps/v8/tools/testrunner/local/pool.py when the internal_error flag was set, meaning a worker process raised an unhandled exception while processing a test workload. The original traceback is logged via logging.exception('Unhandled error during pool execution.') before this generic wrapper is raised, so the real cause is in the log output just above this message.

Source

Thrown at deps/v8/tools/testrunner/local/pool.py:293

            continue
          finally:
            if self.abort_now:
              # SIGINT, SIGTERM or internal hard timeout.
              return

          yield result
          break

        self.advance(gen)
    except KeyboardInterrupt:
      assert False, 'Unreachable'
    except Exception:
      logging.exception('Unhandled error during pool execution.')
    finally:
      self._terminate()

    if internal_error:
      raise Exception('Internal error in a worker process.')

  def _advance_more(self, gen):
    while self.processing_count < self.num_workers * self.BUFFER_FACTOR:
      try:
        self.work_queue.put(next(gen))
        self.processing_count += 1
      except StopIteration:
        self.advance = self._advance_empty
        break

  def _advance_empty(self, gen):
    pass

  def add(self, args):
    """Adds an item to the work queue. Can be called dynamically while
    processing the results from imap_unordered."""
    assert not self.terminated

View on GitHub (pinned to 1b2de5e052)

Solutions

Read the lines immediately above this error in the log: logging.exception already printed the real worker traceback — fix the underlying cause there.
If no traceback is visible, run with --verbose or a single worker (-j1) to surface the worker-side exception directly.
For OOM/segfaults, reduce parallelism (-j), increase swap, or isolate the crashing test with --cat/--isolated-script-test-perf-output.
Ensure all objects returned from worker tasks are picklable (no lambdas, no open file handles) if you extended the test backend.

Example fix

# before
./tools/run-tests.py -j8 ...
# after (surface the real worker error)
./tools/run-tests.py -j1 --verbose ...

Defensive patterns

Strategy: try-catch

Validate before calling

null

Type guard

null

Try / catch

try:
    for result in pool.exec():
        handle(result)
except Exception as e:
    if str(e) == 'Internal error in a worker process.':
        logging.error('A worker crashed; see the Unhandled error traceback above. Re-run with -j1 for the real stack.')
    raise

Prevention

Always inspect the logging.exception output above this generic message for the real cause.
Re-run with a single worker (-j1) to surface worker-side tracebacks.
Keep all worker-returned objects picklable (no lambdas, sockets, or file handles).

When it happens

Trigger: A worker in the multiprocessing pool throws (e.g. test binary segfault, OOM kill, serialization error returning a non-picklable result, or a bug in the test backend) and sets internal_error. After the pool drains and terminates, the main process raises 'Internal error in a worker process.'

Common situations: Running the V8 test suite (tools/test-wrapper-gypbuild.py / tools/run-tests.py) where a d8 child crashes or a result object is unpicklable; running out of memory on large fuzz tests; a Python-version mismatch breaking pickle of result objects.

Related errors

AI-assisted analysis of nodejs/node@1b2de5e052 (2026-08-13). Data as JSON: /api/errors/20a90a11d5d48c80. Report an issue: GitHub.