[rush] rushd: cancelling rushx-client (Ctrl+C/SIGTERM) SIGKILLs the script without a graceful signal and exits 1 with "An unknown error occurred."
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
- 40/100
Hướng nghiên cứu
The issue is in libraries/rush-daemon/src/GlobalCommandExecutionContext.ts, specifically the terminateChild method. Start by examining how requestCancel is handled and how signals are forwarded. Look at SubprocessTerminator.killProcessTree and the mapping in CommandResultPolicy.ts. The fix involves adding a graceful signal phase before SIGKILL, modifying the requestCancel payload to carry the signal, and adjusting exit codes. Test with a script that traps signals to verify graceful termination.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Summary
rushx-client forwards SIGINT/SIGTERM as requestCancel. The daemon then aborts the GlobalCommandExecutionContext, whose terminateChild immediately calls SubprocessTerminator.killProcessTree, which is process.kill(-pid, 'SIGKILL'). The script never receives SIGINT or SIGTERM. Dev servers leave lock/pid files and ports behind, and test runners skip teardown. RushXCommand then reports the killed shell as Error: An unknown error occurred., and the client exits 1 instead of 130/143.
Repro steps
Take a rushx script that traps SIGINT/SIGTERM/SIGHUP, writes a marker file, and exits 40.
| action | rushx-client (daemon) | native rushx |
|---|---|---|
| SIGINT to the client | exit 1, child SIGKILLed, trap not run, prints "Error: An unknown error occurred." | terminal Ctrl+C: trap runs, exit 130 |
| SIGTERM to the client | exit 1, trap not run, same message | exit 143 |
To its credit, the daemon kills the whole tree, so no orphans are left behind.
Expected result: Emulate a terminal Ctrl+C. Send the same signal (SIGINT/SIGTERM) to the script's process group, wait a bounded grace period (for example 2-5 s, within the client's cancellation timeout), then SIGKILL. The client exits 128 + signo and does not print a bogus "unknown error".
Actual result: The script is killed immediately with SIGKILL, the client exits 1, and the message is misleading.
Details
Root cause (main @ 60007c9a8c): libraries/rush-daemon/src/GlobalCommandExecutionContext.ts:343-355 (terminateChild) calls killProcessTree (SIGKILL) directly. CommandResultPolicy.ts:65-68 maps the result to exit code 1.
Suggested fix: add a graceful phase: process.kill(-child.pid, requestSignal ?? 'SIGINT'), then killProcessTree after a grace timeout. Carry the client's signal in requestCancel (for example an additive optional signal field). Suppress the "unknown error" message for aborted requests, and return 130/143 (related: #6060, for phased builds).
This was found during an automated performance/behavior analysis of rush-client/rushd on Linux and independently reproduced.
Standard questions
| Question | Answer |
|---|---|
@microsoft/rush globally installed version? |
built from main @ 60007c9a8c (5.179.0) |
rushVersion from rush.json? |
5.179.0 |
pnpmVersion, npmVersion, or yarnVersion from rush.json? |
[email protected] |
(if pnpm) useWorkspaces from pnpm-config.json? |
true |
| Operating system? | Linux (WSL2 Ubuntu 24.04) |
| Would you consider contributing a PR? | Yes |
Node.js version (node -v)? |
22.23.2 |
- Ngôn ngữ chính
- TypeScript
- Star
- 6.5k
- Fork
- 708
- Merge trung bình
- 4 ngày 7 giờ
- Pull request đã merge (30 ngày)
- 61
Chuẩn bị môi trường
Chúng tôi chưa kiểm tra các tệp thiết lập môi trường của dự án này. Hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
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 microsoft/rushstack
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
microsoft/rushstack#5971 · 2 bình luận ·
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 65/100
microsoft/rushstack#5902 · 1 reaction ·
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 68/100
microsoft/rushstack#5839 · 1 reaction ·
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 70/100
microsoft/rushstack#5683 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của microsoft/rushstack
Issue tương tự
-
module-request
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
ports get and web print 'Port N already in use, trying next...' for every busy port they skipĐang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100
appandflow/stim#1604 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 92/100
lingdojo/kana-dojo#31060 · 1 bình luận · 5 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
SSH workspace restore rewrites relative symlinks into the deleted sync-back staging directoryĐang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100
paperclipai/paperclip#14173 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
needs-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
Maintainer thường phản hồi trong vòng 1 ngày