Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Geschlossen
  • Stimmt etwas nicht?
#2,824 6 Kommentare 0 Reaktionen 1 zugewiesene Person Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@naokihaba arbeitet bereits daran.

Seit 25.9.2026.

Bewertung

Dieses Issue wurde noch nicht bewertet.

Beschreibung

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.

Vorherrschende Sprache
Rust
Sterne
6.5k
Forks
296
Ø Merge
1 T. 59 Min.
Gemergte PRs (30 T.)
235

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus voidzero-dev/vite-plus

Alle Issues in voidzero-dev/vite-plus

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.