Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#2,824 3 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@naokihaba ci sta già lavorando.

Dal 25/9/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

bug
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. #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 #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.

Lingua principale
Rust
Stelle
5.8k
Fork
267
Merge medio
21h 2m
PR unite (30g)
149

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di voidzero-dev/vite-plus

Tutte le issue di voidzero-dev/vite-plus

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.