node --process-timeout blames the main thread when exit waits on a blocked Worker

[trivikr]

Version

main

Platform

All

Subsystem

src (--process-timeout)

What steps will reproduce the bug?

import { Worker } from 'node:worker_threads';

const worker = new Worker(`
  const { execFileSync } = require('node:child_process');
  const { parentPort } = require('node:worker_threads');
  parentPort.postMessage('blocking');
  execFileSync(process.execPath, ['-e', 'setTimeout(() => {}, 10_000)']);
`, { eval: true });

worker.once('message', () => {
  setTimeout(() => process.exit(0), 200);
});

Run with

node --process-timeout=1s repro.js

How often does it reproduce? Is there a required condition?

Always

What is the expected behavior? Why is that the expected behavior?

The message should say the process was already exiting, as it does when the same Worker blocks a natural exit (e.g. worker.unref() instead of process.exit(0)):

(node:PID) Process timed out after 1s (--process-timeout). Exiting with code 124.
The process did not finish exiting after the event loop had stopped.

The main thread is blocked, but only because the exit path is joining a Worker thread that is stuck in execFileSync, not because of a synchronous operation in user code.

What do you see instead?

(node:PID) Process timed out after 1s (--process-timeout). Exiting with code 124.
The main thread did not respond within 2000ms. It is likely blocked in a synchronous native operation, e.g. child_process.execSync() or a native addon, so no JavaScript stack or resource information is available.

Additional information

This is not specific to process.exit(). The same message appears when the process exits because of an uncaught exception or an unhandled rejection, e.g. replace process.exit(0) in the repro with throw new Error('boom') or Promise.reject(new Error('boom')).