Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

[rush] rushd: Ctrl+C on rush-client build does not stop running operations; the client exits 1 after 5 s (instead of 130/143) while other clients stay blocked

已关闭
  • 哪里不对？
#6,060 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
45/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
nodejs, shell, typescript
领域
build-system, cli, tooling

调研方向

The issue is in the rush daemon's operation cancellation logic. Start by examining libraries/rush-lib/src/logic/operations/OperationGraph.ts around line 630 for abortCurrentIterationAsync, and libraries/rush-daemon/src/PhasedRequestRouter.ts lines 484-527 for how cancellation is handled. Look at how GlobalCommandExecutionContext uses SubprocessTerminator.killProcessTree for process termination. The fix involves modifying the abort signal propagation to operation runners and updating the client exit code handling in apps/rush-cli-client/src/launchClient.ts. Testing requires setting up a synthetic workspace with long-running operations to verify cancellation behavior.

由索引模型根据 Issue 内容生成。

描述

Summary

rush-client build handles SIGINT/SIGTERM by sending requestCancel. The daemon then calls OperationGraph.abortCurrentIterationAsync(), which by design only prevents unstarted operations. Running operation processes are never terminated, and the abort waits for every in-flight operation to finish naturally. So after Ctrl+C:

  • the client gives up after 5 s with Daemon did not finish cancellation; disconnected without retrying the command. and exits 1 (native Rush exits 130 for SIGINT and 143 for SIGTERM);
  • the cancelled operation keeps running to completion (about 26 s in our repro), holding the execution lease, so other clients stay blocked behind a build nobody wants.

Repro steps

# 8-project synthetic workspace, p02 build sleeps 30 s; RUSH_DAEMON=1; rush-client from main @ 60007c9a8c
rush-client build & C=$!; sleep 8; kill -INT $C       # p02 is running
sleep 1; rush-client build --only p05                  # second client

Expected result: Cancellation promptly terminates the running operations' process trees (native Ctrl+C in a terminal kills the whole foreground process group), marks them Aborted (no cache write), releases the lease, and returns an aborted result well under a second. The client exits 130/143 and prints a short cancellation notice.

Actual result: At t=13.2 s the client exits 1. p02 keeps running until t≈34 s. The second client is blocked about 26 s and exits 0 at 38.2 s. With 3 s operations, cancel latency equals the remaining time of the running operation (median about 2.1 s), and in 1 of 8 runs a new operation started 9 ms after the signal. The exit code was 1 for SIGINT in 8 of 8 runs, and 1 for SIGTERM.

Details

Root cause (main @ 60007c9a8c):

  • libraries/rush-lib OperationGraph.ts:630 abortCurrentIterationAsync is a soft abort (watch-mode semantics). Running runners get no abort signal, and the signal is only checked before an operation starts (:998).
  • libraries/rush-daemon/src/PhasedRequestRouter.ts:484-527 uses that soft abort for client cancellation. The daemon already has process-tree termination for global commands (GlobalCommandExecutionContext → SubprocessTerminator.killProcessTree), but not for phased operations.
  • Exit code: the daemon returns { outcome: 'aborted', exitCode: 1 } (CommandResultPolicy.ts:67-68), and apps/rush-cli-client/src/launchClient.ts:170-171 copies it verbatim. The 130 branch (:179) only handles non-result outcomes.

Suggested fix: add a hard-abort path. Pass the iteration abort signal to operation runners, and have the shell and IPC runners kill their subprocess tree on abort (report Aborted, skip the cache write). Use it when the last live participant of a batch cancels, and keep the soft abort for watch-mode invalidation. In the client, exit 128 + signo and print rush-client: build cancelled. Handle SIGHUP like SIGTERM.

This was found during an automated performance/behavior analysis of rush-client/rushd on Linux and reproduced independently twice (including the coalesced case: cancelling 1 of 3 coalesced clients works for the other 2, but the cancelled client still waits 5 s and exits 1).

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
主要语言
TypeScript
星标
6.5k
派生
708
平均合并
4 天 7 小时
30 天内合并 PR
61

环境准备

我们还没有检查这个项目的环境配置文件。先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

microsoft/rushstack 的其他 Issue

查看 microsoft/rushstack 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。