vp run: task output forwarding aborts with EAGAIN when stdout turns non-blocking mid-run (follow-up to #2165)

[korya]

Describe the bug

vp run -r <task> aborts with Failed to forward task process output: Resource temporarily unavailable (os error 11) (Linux, GitHub Actions) or os error 35 (macOS), then kills the other running tasks (exit 137). No test fails; the run is lost because output forwarding hit EAGAIN.

This is the same root cause as #2165. The fix there (#2173, ensureBlockingStdio() at startup) is present in our version, but it clears O_NONBLOCK only once. The flag gets set again mid-run on the shared stdout description, and the task-output forwarding path does not handle WouldBlock.

What we observed

We sampled os.get_blocking(1) every 50–200 ms from a sibling process sharing the same stdout pipe, with a deliberately slow reader (… | (sleep 25; cat)):

Run	Non-blocking windows on the shared stdout
vp run -r test, full workspace	0.1–0.3 s, then 25.4–28.6 s, even when invoked as ./node_modules/.bin/vp (no package manager in between)
vp run --filter <pkg> test, where test is a package.json script running playwright test	1.4–4.5 s
playwright test on its own	0.4–3.6 s

• The mid-run window appears when the reader starts draining a full pipe. That points at Node re-marking its non-TTY stdout non-blocking under backpressure. Any ForwardTaskProcessOutput write landing in that window fails with EAGAIN.
• Uncached tasks make it worse. vite-task runs them with inherited stdio (crates/vt/src/session/execute/mod.rs: Uncached { pipe_writers: None } => SpawnStdio::Inherited), so a Node child such as Playwright marks the shared description non-blocking for seconds while other tasks' captured output is being forwarded.
• A regular-file sink never fails (vp run -r test > out.log), which is consistent with EAGAIN on the write side.

Reproduction

1. A workspace with several vp test tasks producing a few thousand lines of output, plus one package whose test is a package.json script (uncached, so it inherits stdio) running a Node tool, for example playwright test.
2. Run with a stdout consumer that lags:

   vp run -r test 2>&1 | (sleep 25; cat > /dev/null)
   vp run --last-details

3. The details show one task with ✗ Error: Failed to forward task process output: Resource temporarily unavailable (os error 35) and the rest ✗ (exit code: 137).

On GitHub Actions it reproduced on 2 of 2 runs for one change set, and passed once we removed one test task from the run, which changed the task schedule. That makes it timing dependent, and silent until it isn't.

Versions

• vite-plus 0.2.9, which already calls ensureBlockingStdio() in dist/bin.js.
• Node 24.21, macOS 26.5 (arm64) and GitHub Actions ubuntu-24.04-arm.
• We have not run 0.3.x or 1.0.0-rc.0, but vite-task main (8dd41bc8) has no WouldBlock handling in pipe_stdio / ForwardTaskProcessOutput. fix(cli): handle broken pipes in command output #2785 adds a retrying writer only for --version and env list-remote.

Suggested fix

• Retry WouldBlock in the forwarding writer (poll the fd for writability, then retry), like the print_and_flush helper from fix(cli): handle broken pipes in command output #2785, rather than treating EAGAIN as fatal.
• Alternatively, or as well, re-assert blocking mode on the sinks before writing. Clearing it once at startup cannot cover Node re-marking the description later, or inherited children marking it.

Workaround

Send vp's output to a regular file in CI and print it afterwards (vp run -r test > log 2>&1; rc=$?; cat log; exit $rc).

Related: #2165, #2173, #2169, #2785.

[naokihaba]

@korya
Thanks for looking into this so thoroughly. Could you see if this still happens on either the latest 0.3.x release or 1.0.0-rc.0 and let us know the exact version and result? If possible, a minimal reproduction repo or CI workflow (with your task definitions and Playwright script) would be super helpful so we can verify the issue and test a fix against it.

[github-actions]

Hello @korya 👋

Please provide a minimal reproduction using a GitHub repository. This helps us understand and resolve your issue much faster.

A good reproduction should be:

• Minimal – include only the code necessary to demonstrate the issue
• Complete – contain everything needed to run and observe the problem
• Reproducible – consistently show the issue with clear steps

If no reproduction is provided, issues labeled needs reproduction will be closed after 3 days of inactivity.

For more context on why this is required, please read: https://antfu.me/posts/why-reproductions-are-required

[korya]

Thanks @naokihaba. It still happens on the latest releases. Here is a minimal reproduction.

Repro repo: https://github.com/korya/vp-eagain-repro. The README has step-by-step instructions, expected output and controls.

It has two workspace packages, each with a go task:

• noisy: a cached vp task, so vp captures its output and forwards it. It writes about 5 MB and misses the cache every run.
• holder: a package.json script, so it runs uncached and inherits vp's stdout. It is a Node process holding that stdout for 8 s.

GitHub Actions results. No artificial slowdown: the Actions log reader is the only reader, 5 runs per cell (run):

vite-plus	ubuntu-latest	ubuntu-24.04-arm
0.2.9	5/5 fail	4/5 fail
0.3.3	5/5 fail	5/5 fail
1.0.0-rc.0	5/5 fail	5/5 fail

Each failure is ✗ Failed to forward task process output: Resource temporarily unavailable (os error 11), and the other task is killed with exit code 137.

Locally (macOS 26.5 arm64, Node 24.21, 3 runs per cell, reader delayed with | (sleep 5; cat)):

vite-plus	both tasks	noisy alone	both tasks, output to a file
0.2.9 / 0.3.3 / 1.0.0-rc.0	fail 3/3	pass 3/3	pass 3/3

Both tasks in a real TTY (script -q /dev/null …) passed 3/3 on 1.0.0-rc.0.

A correction to my report. I said vp's own backpressure could trigger it. In the minimal case it doesn't: noisy alone passes. The trigger is a Node process in an uncached, stdio-inheriting task (SpawnStdio::Inherited) running while a captured task's output is being forwarded. Node marks the shared stdout description O_NONBLOCK, so ensureBlockingStdio() at startup doesn't help.

How the Actions reader drains a step's stdout. Measured with scripts/pipe-probe.py: it sets stdout non-blocking and writes 20 MB in bursts.

• The pipe filled 276–299 times.
• The median stall was 1.1 ms, and the longest was 7.5 ms (arm) or 17.5 ms (x64).
• The whole 20 MB took about 1.3 s.

So a slow or stalled reader isn't needed. The pipe routinely fills for about a millisecond, and a single un-retried EAGAIN in the forwarder is enough.

Workaround we use in CI: send vp's output to a regular file and stream it to the log with GNU tail -f --pid (only tail, with blocking writes, touches the CI pipe). Happy to test a fix branch against the repro.