[PR #2784] [CLOSED] fix(windows): drain owned-process output without the 25ms idle delay #5392

New issue

Closed

opened 2026-10-31 01:06:17 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 01:06:17 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/2784
Author: @sx4im
Created: 10/13/2026
Status: ❌ Closed

Base: main ← Head: fix/2722-windows-output-drain

📝 Commits (10+)

eac36f8 fix(windows): drain owned-process output without the 25ms idle delay
bdd5f69 test(windows): cover idle pacing and stderr-only drain timing
be6e805 chore: merge upstream main into fix/2722-windows-output-drain
044ca36 fix(windows): back off to the idle delay when the consumer stops accepting output
34421f7 fix(windows): pause native output polling until consumers drain
1b27196 fix(android): make DEX descriptor pattern portable
12c3169 fix(ci): isolate Linux Hopper process fixture inventory
264792a fix(comparison): recheck historical calls-only changes (#2223)
17d2e46 fix(windows): resume owned process drain lifecycle
161e055 fix(windows): keep draining unblocked process output

📊 Changes

4 files changed (+333 additions, -11 deletions)

View changed files

📝 src/process/ProviderProcess.ts (+10 -2)
📝 src/process/ProviderProcessOutput.test.ts (+24 -0)
📝 src/windows/WindowsOwnedProcess.test.ts (+220 -1)
📝 src/windows/WindowsOwnedProcess.ts (+79 -8)

📄 Description

On Windows, inspect-wasm-artifact fails with provider_timeout for modules whose WAT output is larger than about 7.9 MB, even though the child process itself finishes in about a second. #2722 measured capture at ~262 KB/s through the Windows owned-process path.

Root cause: WindowsOwnedProcess re-polls the native process_poll on a fixed 25ms timer, and each poll pulls a single chunk from the pipe. That caps capture at roughly one chunk per poll interval no matter how much data is waiting, so the 30s deadline always fires before large outputs finish draining.

Changed src/windows/WindowsOwnedProcess.ts: #schedule now takes a delay, and #poll passes 0 when the last poll returned stdout or stderr data, 25 when the child was idle. Capture now drains at pipe speed while the child produces output and still backs off when there is nothing to read. The 25ms default is unchanged for the launch and cleanup paths.

Verified with a new test in src/windows/WindowsOwnedProcess.test.ts that replays 10 full 8 KiB stdout polls plus a settle poll against a mock native authority under fake timers: on the old code only 4 polls complete in 100ms of simulated time (the test fails); with the fix all 11 complete. Full src/windows suite: 30/30 pass. tsc --noEmit clean, oxlint 0 errors (1 pre-existing warning).

Caveat: I can't run the Windows native side here, so this is verified at the TS polling layer against the mocked authority, which is where the throttle lived. The native readOutput already returns up to 64 KiB per call; it just wasn't being called often enough.

Fixes #2722

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/2784 **Author:** [@sx4im](https://github.com/sx4im) **Created:** 10/13/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix/2722-windows-output-drain` --- ### 📝 Commits (10+) - [`eac36f8`](https://github.com/morluto/rea/commit/eac36f8b6fae68db9c217cc846f0efef588271e3) fix(windows): drain owned-process output without the 25ms idle delay - [`bdd5f69`](https://github.com/morluto/rea/commit/bdd5f69d7dc5acb24256a4bef7306a32f7019fd2) test(windows): cover idle pacing and stderr-only drain timing - [`be6e805`](https://github.com/morluto/rea/commit/be6e805379c13dc92cf2431bbd48f69a70a12d61) chore: merge upstream main into fix/2722-windows-output-drain - [`044ca36`](https://github.com/morluto/rea/commit/044ca36aebf0bd306b302fdb40d709f6c6560ba0) fix(windows): back off to the idle delay when the consumer stops accepting output - [`34421f7`](https://github.com/morluto/rea/commit/34421f75a2b4ce7021186a846c5a855c3c2d36e7) fix(windows): pause native output polling until consumers drain - [`1b27196`](https://github.com/morluto/rea/commit/1b271969700ae867cadc3f2329ae10e758701a6f) fix(android): make DEX descriptor pattern portable - [`12c3169`](https://github.com/morluto/rea/commit/12c31694b65c05402cbaf1678ab860e7992c9ab5) fix(ci): isolate Linux Hopper process fixture inventory - [`264792a`](https://github.com/morluto/rea/commit/264792adc558e4e99d7412022b3cbb1994146cf4) fix(comparison): recheck historical calls-only changes (#2223) - [`17d2e46`](https://github.com/morluto/rea/commit/17d2e46bc780862b41d65c0d0aae3f88716c1b44) fix(windows): resume owned process drain lifecycle - [`161e055`](https://github.com/morluto/rea/commit/161e0555c28dceded50ca47a9e9451854b4b10af) fix(windows): keep draining unblocked process output ### 📊 Changes **4 files changed** (+333 additions, -11 deletions) <details> <summary>View changed files</summary> 📝 `src/process/ProviderProcess.ts` (+10 -2) 📝 `src/process/ProviderProcessOutput.test.ts` (+24 -0) 📝 `src/windows/WindowsOwnedProcess.test.ts` (+220 -1) 📝 `src/windows/WindowsOwnedProcess.ts` (+79 -8) </details> ### 📄 Description On Windows, `inspect-wasm-artifact` fails with `provider_timeout` for modules whose WAT output is larger than about 7.9 MB, even though the child process itself finishes in about a second. #2722 measured capture at ~262 KB/s through the Windows owned-process path. Root cause: `WindowsOwnedProcess` re-polls the native `process_poll` on a fixed 25ms timer, and each poll pulls a single chunk from the pipe. That caps capture at roughly one chunk per poll interval no matter how much data is waiting, so the 30s deadline always fires before large outputs finish draining. Changed `src/windows/WindowsOwnedProcess.ts`: `#schedule` now takes a delay, and `#poll` passes 0 when the last poll returned stdout or stderr data, 25 when the child was idle. Capture now drains at pipe speed while the child produces output and still backs off when there is nothing to read. The 25ms default is unchanged for the launch and cleanup paths. Verified with a new test in `src/windows/WindowsOwnedProcess.test.ts` that replays 10 full 8 KiB stdout polls plus a settle poll against a mock native authority under fake timers: on the old code only 4 polls complete in 100ms of simulated time (the test fails); with the fix all 11 complete. Full `src/windows` suite: 30/30 pass. `tsc --noEmit` clean, `oxlint` 0 errors (1 pre-existing warning). Caveat: I can't run the Windows native side here, so this is verified at the TS polling layer against the mocked authority, which is where the throttle lived. The native `readOutput` already returns up to 64 KiB per call; it just wasn't being called often enough. Fixes #2722 --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-31 01:06:17 +00:00