[rush] rush-cli-client/rushd: daemon-path error UX gaps (leaked engine chatter, transport jargon, RUSH_DAEMON_* typo blocks --no-daemon, non-Git workspaces hard-fail instead of falling back, ...)

[TheLarkInn]

Summary

A bundle of daemon-path error-UX problems. Each one is small, but together they make daemon errors noticeably worse than native errors for both humans and AI agents. The items below were reproduced with rush-client from main @ 60007c9 and RUSH_DAEMON=1, and items 1, 3, 4 and 7 were independently confirmed.

1. Engine chatter leaks into rejections. rush-client build -t nosuchproj prints rush-client: Daemon rejected the request (invalidRequest): Incremental strategy: cache restoration\n\nThe project name "nosuchproj" passed to "--to" does not exist in rush.json.\n\nAn error occurred. Native Rush prints only the middle sentence. Cause: EngineTerminalProvider.describeError (libraries/rush-daemon/src/EngineTerminalProvider.ts:19-24) prepends every buffered info/verbose line (used at ProductionDaemonRequestResolver.ts:111, 162, 190). Include only warning and error severities.
2. Transport jargon prefix. Every daemon-side configuration or validation error is wrapped as Daemon rejected the request (routingFailed|invalidRequest): ... (apps/rush-cli-client/src/launchClient.ts:215-216). For user errors, print the native text and keep the code for --verbose.
3. A typo in a RUSH_DAEMON_* variable disables the escape hatch. RUSH_DAEMON_FOO=1 rush-client build --no-daemon and ... rush-client --help both exit 1 with Unknown daemon environment variable "RUSH_DAEMON_FOO"., because resolveDaemonConfiguration runs before routing (launchClient.ts:43-46). --no-daemon, --help and never-daemonize commands should not require a valid daemon configuration.
4. Misleading numeric error. RUSH_DAEMON_QUEUE_TIMEOUT_SECONDS=-1 reports must be a decimal number., because the regex rejects the sign before the range check (DaemonConfiguration.ts:131-132).
5. rush.json daemon block errors have no location. {"enabled":"yes"} reports daemon.enabled must be a boolean. Native schema errors include the file path and JSON pointer.
6. Duplicated error on fallback. A command-line.json syntax error prints the full error in the fallback notice, and then native Rush prints the identical error again (launchClient.ts:217-218).
7. rush-client daemon --help and daemon logs --help exit 1. Help should exit 0. There's also a punctuation glitch in the fallback message: ...require --no-daemon.; using in-process Rush.
8. Non-Git workspaces hard-fail instead of falling back. In a workspace that is not a Git checkout (tarball, git archive export, a Docker context without .git), with RUSH_BUILD_CACHE_ENABLED=0, native rush build succeeds, but rush-client build exits 1 with routingFailed ... The daemon engine requires a Git-backed workspace inputs snapshot. (right after "Rush will proceed without incremental build support"). Throw a typed error from rush-lib (PhasedScriptAction.ts:820-823) and map it to an unsupported rejection so that the client falls back in-process. (Item 8 was reproduced by one analysis run, and a prototype of the fix worked.)

Repro steps

See each item's command above. All of them were run in a synthetic workspace.

Expected result: Errors on the daemon path match native Rush's clarity and exit codes.

Actual result: As listed.

Details

This was found during an automated performance/behavior analysis of rush-client/rushd on Linux.

Standard questions

Question	Answer
@microsoft/rush globally installed version?	built from main @ 60007c9 (5.179.0)
rushVersion from rush.json?	5.179.0
pnpmVersion, npmVersion, or yarnVersion from rush.json?	pnpm@10.27.0
(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