Windows cached task hangs after first compound command when stdio pipe remains open

Aperta

#485 aperta il 24/6/2026 1 commento 1 reazione 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà: 4/5
Tempo stimato: 3-5 giorni
Idoneità per principianti: 52/100

Tipo di issue: Bug
Chiarezza: Abbastanza chiara
Stato di attività: Tranquilla
Stack tecnologico: github-actions, rust
Ambito: cli, operating-systems

Direzione di ricerca

Inizia dal percorso di esecuzione in cache e dalla relativa gestione delle pipe stdout/stderr del processo figlio Windows, quindi riproduci il comando composto usando il repository di riproduzione collegato e confrontalo con l’esecuzione con --no-cache. Il lavoro è completo quando l’esecuzione Windows in cache passa al secondo comando dopo l’uscita del primo processo figlio, senza lasciare un processo vctip orfano.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

On Windows, a cached vp run task can hang after the first command in a compound script has completed, before the next && command starts.

This was reproduced with a script shape similar to:

{
  "scripts": {
    "test": "cargo test -p ox_mf2_parser --all-targets --color always && vp test"
  }
}

Reproduction

Repro repo: https://github.com/kazupon/vite-task-windows-issue-1
(cause repo: https://github.com/intlify/intlify)

In GitHub Actions, the normal cached Windows run hangs, while the Windows --no-cache control run completes successfully.

Observed behavior

The cached run prints and completes the cargo test output, but never prints or starts the following $ vp test command.

Process snapshots show only the vpr / vp / node runner process tree remaining. No cargo, rustc, or vitest process remains. At workflow cleanup, GitHub Actions reports an orphaned vctip process.

Expected behavior

After the direct child process for the first command exits, the runner should observe completion and continue to the next && command, even if a descendant temporarily keeps stdout/stderr handles open.

Suspected cause

The cached execution path drains piped stdout/stderr before awaiting the direct child process. On Windows, if a descendant keeps an inherited pipe handle open, EOF never arrives, so the runner never reaches child wait or Windows Job Object cleanup.

Lingua principale: Rust
Stelle: 466
Fork: 42
Merge medio: 1g 20h
PR unite (30g): 21

Guida per i contributori

Apri la guida per i contributori

Come iniziare

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