[rush] rushd: cancelling rushx-client (Ctrl+C/SIGTERM) SIGKILLs the script without a graceful signal and exits 1 with "An unknown error occurred."
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 40/100
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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 |
- Lenguaje dominante
- TypeScript
- Estrellas
- 6.5k
- Forks
- 708
- Merge medio
- 4 d 13 h
- PR fusionados (30 d)
- 62
Preparar el entorno
Aún no hemos revisado los archivos de configuración de este proyecto. Empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de microsoft/rushstack
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
microsoft/rushstack#5971 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
microsoft/rushstack#5902 · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
microsoft/rushstack#5839 · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
microsoft/rushstack#5683 · 3 comentarios ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
Los mantenedores suelen responder en 1 día
Todos los issues de microsoft/rushstack
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
diegosouzapw/OmniRoute#14869 ·
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 94/100
Los mantenedores suelen responder en 1 día
-
status: waiting triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
freeCodeCamp/freeCodeCamp#70412 ·
Los mantenedores suelen responder en 1 día
-
Mend: dependency security vulnerability untriaged
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
opensearch-project/OpenSearch-Dashboards#12816 ·
Los mantenedores suelen responder en 1 día