Windows cached task hangs after first compound command when stdio pipe remains open
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 52/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- github-actions, rust
- Domain
- cli, operating-systems
Research direction
Start with the cached execution path and its Windows child-process stdout/stderr pipe handling, then reproduce the compound command using the linked repro repository and compare it with the --no-cache run. Done means the cached Windows run proceeds to the second command after the first child exits, without leaving an orphaned vctip process.
Written by the indexing model from the issue text.
Description
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.
- Dominant language
- Rust
- Stars
- 466
- Forks
- 42
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 21
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from voidzero-dev/vite-task
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
voidzero-dev/vite-task#738 · 1 comment ·
-
Difficulty 3/5 1-2 days Newbie friendliness 78/100
voidzero-dev/vite-task#719 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
voidzero-dev/vite-task#717 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
voidzero-dev/vite-task#702 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
voidzero-dev/vite-task#700 · 2 comments ·
All issues in voidzero-dev/vite-task
Similar issues
-
Browser (wasm) relay client cannot connect to relays whose URL has a trailing-dot FQDN hostname Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
n0-computer/iroh#4550 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
paritytech/zombienet-sdk#591 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
farion1231/cc-switch#7638 · 1 comment ·
-
onnx-ir re-exports ModelProto and GraphProto but not NodeProto, AttributeProto and AttributeType Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100