`vp run`: an option to keep going after a task fails (today one failure kills unrelated running tasks and their results are lost)
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 35/100
Hướng nghiên cứu
Start in crates/vt/src/session/execute/scheduler.rs, where a failure cancels the shared token (around lines 229-231), and in cache_update.rs, where cancelled runs are skipped for caching (around lines 48-49). A --continue flag would need to stop that cancellation, skip only tasks that depend on a failure, and set a non-zero exit code at the end. Done means a fixture with independent failing and passing packages finishes the passing ones, caches them, and exits non-zero. The issue is a feature with a design choice (which continue modes to support), so confirm the scope with maintainers before starting.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Summary
When a task fails, vp run cancels the whole run. Tasks that are running and do not depend on the failed task are killed, tasks not yet started never run, and none of them gets a cache entry. There is no option to change this.
This asks for one: keep running every task whose dependencies succeeded, skip only the tasks that depend on a failure, and exit non-zero at the end.
What happens today
A workspace of four packages with no dependencies between them. a fails after 2 s; b, c and d take 8 s.
// packages/a/package.json
{ "name": "a", "scripts": { "check": "node -e \"setTimeout(() => process.exit(1), 2000)\"" } }
// packages/b/package.json (c and d are the same)
{ "name": "b", "scripts": { "check": "node -e \"setTimeout(() => console.log(1), 8000)\"" } }
$ vp run --cache -r check
vp run: 0/4 cache hit (0%), 4 failed.
$ vp run --last-details
[1] a#check ... ✗ (exit code: 1)
[2] c#check ... ✗ (exit code: 137)
[3] d#check ... ✗ (exit code: 137)
[4] b#check ... ✗ (exit code: 137)
The run ends after about 2 s. b, c and d were healthy and independent of a. They are reported as failed, and the next run starts them from nothing. (vp v1.0.0, macOS.)
In the source this is unconditional. The scheduler cancels the shared token on any failure (scheduler.rs#L229-L231), and a run cancelled that way is not cached (cache_update.rs#L48-L49).
Why it matters
- One failure per run. In a recursive
testorlintover many packages, the first failure hides every other one. A change that breaks three packages takes three runs to fix, and in CI each run is a round trip. - A flake costs the whole run. One test that times out kills every suite still running. Their results are lost, so the retry re-executes work that was about to pass.
- The killed tasks read as failures. They show
exit code: 137beside the real failure and the summary counts them as failed, so the reader has to work out which one was the cause. - The workaround is expensive. To get a result per package, a CI job has to start one
vp run <package>#<task>process per package. Those processes then replay the same dependency tasks at the same time, and a cache hit restores a task's outputs over the existing files while another process is reading them. So the job also has to run the shared dependencies once up front and pass--ignore-depends-onto every process.
Prior art
| Tool | Option | Its documentation |
|---|---|---|
| GNU Make | -k, --keep-going |
"Keep going when some targets can't be made." |
| Turborepo | turbo run --continue[=never|dependencies-successful|always] |
Default never. With dependencies-successful: "turbo will cancel dependent tasks. Tasks whose dependencies have succeeded will continue to run." |
| pnpm | pnpm run --no-bail |
"Continue running the remaining matched scripts even if one of them fails. The command still exits with a non-zero exit code if any script failed." |
| Nx | --nxBail |
"Stop command execution after the first failed task." |
| Cargo | cargo test --no-fail-fast, cargo build --keep-going |
"Run all tests regardless of failure"; "Do not abort the build as soon as there is an error" |
Proposal
vp run --continue [TASK_SPECIFIER]
- A task that fails does not cancel the run.
- A task whose dependencies all succeeded still runs, and its result is cached as in any other run.
- A task that depends on a failed task, directly or through others, does not run. It is reported as skipped, naming the failure it waited on. This is Turborepo's
dependencies-successful. - The run exits non-zero if any task failed, after every runnable task has finished.
- Ctrl-C still cancels everything.
With the example above it would print:
$ vp run --cache --continue -r check
vp run: 0/4 cache hit (0%), 1 failed.
$ vp run --cache --continue -r check
vp run: 3/4 cache hit (75%), 1 failed.
A config key for the default would let a workspace choose it for CI. The flag alone is enough to start.
Non-goals
- Changing the default.
- Running the dependents of a failed task (Turborepo's
always). - Retrying a failed task.
How we hit it
A monorepo of about 80 packages that runs vp run -r test in CI. One test timed out by 10 ms, and three healthy suites that were still running were killed with exit 137. None of the three stored a result, so the retry ran all four again, one of them with 1,282 tests. We now run one process per package to keep each verdict, at the cost described above.
- Ngôn ngữ chính
- Rust
- Star
- 473
- Fork
- 44
- Merge trung bình
- 1 ngày 7 phút
- Pull request đã merge (30 ngày)
- 56
Chuẩn bị môi trường
Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của voidzero-dev/vite-task
-
Windows: automatic filesystem tracking makes Git/MSYS sh.exe fail with MapViewOfFileEx error 487Đang mở
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 18/100
voidzero-dev/vite-task#830 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Let tools mark cache directories with CACHEDIR.TAGCó thể đã có người làm @lifeiscontent đã nhận 8 ngày trước. Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
voidzero-dev/vite-task#793 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Preview cache hits without running tasksCó thể đã có người làm @lifeiscontent đã nhận 9 ngày trước. Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 52/100
voidzero-dev/vite-task#791 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Built-in tool tasks miss the cache after the workspace movesCó thể đã có người làm @lifeiscontent đã nhận 9 ngày trước. Đang mở
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 67/100
voidzero-dev/vite-task#790 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
vp run: output forwarding fails with EAGAIN when an inherited Node child sets stdout non-blockingCó thể đã có người làm @naokihaba đã nhận 6 ngày trước. Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
voidzero-dev/vite-task#782 · 1 bình luận · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của voidzero-dev/vite-task
Issue tương tự
-
C-bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
rust-lang/rust-analyzer#23501 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Streamable HTTP client: a 401 or 403 with a JSON-RPC error body and no WWW-Authenticate loses its HTTP statusCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mởbug P2 ready for work T-security T-transport
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
modelcontextprotocol/rust-sdk#1339 ·
Maintainer thường phản hồi trong vòng 3 ngày
-
French BIP39 wordlist starts with a UTF-8 BOM, so generated French mnemonics carry U+FEFF and derive a non-canonical seedCó thể đã có người làm @Kshot3000 đã nhận hôm nay. Đang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 91/100
ergoplatform/sigma-rust#976 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug]: Web chat input doesn't regain focus after a reply finishesCó thể đã có người làm @GaijinSystems đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
zeroclaw-labs/zeroclaw#11658 ·
Maintainer thường phản hồi trong vòng 2 ngày