[Bug]: Tinypool throws Error: write UNKNOWN

[WesleyHovick]

Version

System:
    OS: Windows 11 10.0.26200
    CPU: (32) x64 AMD RYZEN AI MAX+ 395 w/ Radeon 8060S
    Memory: 23.02 GB / 47.78 GB
Browsers:
    Edge: Chromium (143.0.3650.96)
Binaries:
    Node: 22.22.0
    Yarn: 1.22.22

Details

When bumping from @rstest/core v0.9.4 to either v0.9.5 or v0.9.6, our tests get intermittent failures from tinypool.

On Windows, Node.js named-pipe IPC channels can intermittently throw "Error: write UNKNOWN" when a forked worker process exits while the parent is mid-send. Tinypool ≤ 2.1.0 has no try-catch around this call, so the error propagates up and fails a random test.

We are on node v22.22.0, TypeScript 4.9.5, using Yarn workspaces 1.22.22.

A patch/workaround was to add a try-catch to tinypool so the broken pipe is silently ignored - then the worker's exit handler will handle cleanup. After adding this to tinypool all tests pass on 0.9.5 (haven't tried 0.9.6 yet) - demonstrating the issue, at least on our end.

What changed in 0.9.5+ that would have caused this? Can you consider alternatives to tinypool to mitigate this?

We are in the process of fully migration tens of thousands of tests to rstest from jest and this will be a hard stop for us since this directly seems to cause tests to suddenly fail with no changes on our end from 0.9.4 to 0.9.5+.

Reproduce link

n/a

Reproduce Steps

I don't know exactly what the repro steps are other than I can repro it in our codebase in one of our monorepo packages consistently when on 0.9.5 and 0.9.6. It does not repro on 0.9.4.

[9aoy]

Thanks for the details. Based on the behavior you described, our current suspicion is that this is a Windows child_process IPC shutdown race in the tinypool path, and that the worker timing changes introduced in 0.9.5+ made that race much easier to hit.

We’ve tried a narrow mitigation in rstest on our side: during worker teardown, we now guard a small set of known ignorable IPC send errors instead of letting them surface as random test failures.

Could you please try the preview version @rstest/core@https://pkg.pr.new/@rstest/core@fa4ec71 and see whether it resolves the issue in the package that reproduces consistently for you?

If it still reproduces, it would be especially helpful if you could share the full stack trace from the original write UNKNOWN failure so we can confirm whether the final fix should stay in rstest or be pushed further upstream.

[WesleyHovick]

Thank you for such an impressive response time for this!

I installed the preview version and I can confirm that after running the same tests and setup, this fixes the issue.

All tests pass and after about 10 runs I have not seen a repro.

[WesleyHovick]

Correction... it looks like it does still seem to repro. Will get more details shortly.

[WesleyHovick]

I've only seen it happen once - it was after being idle for a while and coming back. Subsequent runs have been successful.

I'm currently running it multiple times with DEBUG=rstest set (not sure if that will give any more info) to see if I can get it to fail again.

Here is the trace from the 1 failure where DEBUG=rstest was not set.

Error: write UNKNOWN

        at target._send (node:internal/child_process:877:20)
        at target.send (node:internal/child_process:751:19)
        at ProcessWorker.send (file:///C:/Users/[userRedacted]/source/repos/[privateRepoRedacted]/node_modules/tinypool/dist/index.js:101:41)
        at ProcessWorker.patchedSend (file:///C:/Users/[userRedacted]/source/repos/[privateRepoRedacted]/node_modules/@rstest/core/dist/0%7E8843.js:219:33)
        at MessagePort.<anonymous> (file:///C:/Users/[userRedacted]/source/repos/[privateRepoRedacted]/node_modules/tinypool/dist/index.js:110:62)
        at [nodejs.internal.kHybridDispatch] (node:internal/event_target:845:20)
        at MessagePort.<anonymous> (node:internal/per_context/messageport:23:28)


 Test Files 1 failed | 81 passed (82)
      Tests 291 passed | 3 skipped (294)
   Duration 1m 23s (build 38.2s, tests 44.9s)

[WesleyHovick]

Here is all the details I can think of at the moment.

Environment

Component	Version
Node.js	v22.22.0
Rstest (@rstest/core)	0.9.6 (@rstest/core@https://pkg.pr.new/@rstest/core@fa4ec71)
tinypool	2.1.0
OS	Windows (32 CPU cores)
Pool config	Default (no maxWorkers set — defaults to CPU count = 32 workers)

Reproduction

1. Using a package in our monorepo with 82 test files, 289 tests
2. Ran yarn test in a tight loop with a ps script:

   for ($i = 1; $i -le 60; $i++) { yarn test; if ($LASTEXITCODE -ne 0) { break } }

3. Saw the failure after 4th run

Rstest config (minimal)

{
    globals: true,
    include: ["src/**/*.spec.{ts,tsx}"],
    exclude: ["**/node_modules/**", "**/dist/**"],
    testTimeout: 10000,
    restoreMocks: true,
    plugins: [pluginReact()],
    testEnvironment: "jsdom"
}

Error Output

In a recent example run we saw 3 test files fail with the identical error. No test assertion failures - the entire file is marked FAIL due to the IPC crash:

Full Stack Trace

Error: write UNKNOWN

    at target._send (node:internal/child_process:877:20)
    at target.send (node:internal/child_process:751:19)
    at ProcessWorker.send (tinypool/dist/index.js:101:41)
    at ProcessWorker.patchedSend (@rstest/core/dist/0~8843.js:219:33)
    at EventEmitter.<anonymous> (tinypool/dist/index.js:97:9)
    at EventEmitter.emit (node:events:519:28)
    at post (@rstest/core/dist/0~8843.js:246:21)
    at EventEmitter.onMessage (@rstest/core/dist/1983.js:181:27)

Analysis

• The error originates in Node.js's child_process.send() (the IPC channel between parent and worker).
• write UNKNOWN maps to libuv's UV_UNKNOWN errno - a catch-all indicating the IPC pipe write failed for an unrecognized reason.
• This typically means a worker process died or its IPC pipe was closed, and the parent attempted to send it another message.
• No pool configuration is set, so tinypool defaults maxWorkers to the CPU core count (32 in my case). This creates 32 concurrent child processes, which is likely contributing to IPC channel exhaustion on repeated runs.

[9aoy]

Thanks for the stack trace — it helps narrow this down.

It shows the failure is still happening on the parent-side ProcessWorker.send() path, so the previous fix was only partially covering the shutdown race.

We’ve now tightened the mitigation in rstest by:

• skipping sends to workers that are already disconnected / exited
• broadening the Windows UNKNOWN IPC error guard

The update is in the same PR: #1144

Could you try the latest preview version @rstest/core@https://pkg.pr.new/@rstest/core@854bea5 and see if it still repros?

[WesleyHovick]

Unfortunately, the issue still repros. However, the stack trace is slightly different now:

Error: write UNKNOWN
       at target._send (node:internal/child_process:877:20)
       at target.send (node:internal/child_process:751:19)
       at ProcessWorker.send (tinypool/dist/index.js:101:41)
       at ProcessWorker.patchedSend (@rstest/core/dist/0~8843.js:221:33)
       at MessagePort.<anonymous> (tinypool/dist/index.js:110:62)
       at [nodejs.internal.kHybridDispatch] (node:internal/event_target:845:20)
       at MessagePort.<anonymous> (node:internal/per_context/messageport:23:28)

[WesleyHovick]

Some new info - I am actually able to periodically repro this on 0.9.4 as well... seeing a similar stack trace. Occurs roughly 1 in 10 runs.

Error: write UNKNOWN
   
       at target._send (node:internal/child_process:877:20)
       at target.send (node:internal/child_process:751:19)
       at ProcessWorker.send (tinypool/dist/index.js:101:41)
       at MessagePort.<anonymous> (tinypool/dist/index.js:110:62)
       at [nodejs.internal.kHybridDispatch] (node:internal/event_target:845:20)
       at MessagePort.<anonymous> (node:internal/per_context/messageport:23:28)

One thing I will note, it does appear that I get better reliability when setting maxWorkers: "50%".