Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

[rush] rush-cli-client: routing and feedback gaps (non-build commands auto-start the daemon, 0-column TTY hard-fails, no queue or startup feedback for non-TTY clients)

Offen
#6,052 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
65/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
cli, nodejs, typescript

Rechercherichtung

Start in apps/rush-cli-client/src/routing.ts to see the command routing logic and the neverDaemonize list. Check launchClient.ts for TTY column handling and queue feedback. The daemon rejection logic is in ProductionDaemonRequestResolver.ts. Run the repro steps to verify the issues, focusing on one at a time. A fix should ensure non-build commands skip the daemon, handle 0 columns gracefully, provide queue feedback to non-TTY, and give startup status.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Summary

Four related problems in apps/rush-cli-client (the opt-in rush-client), each reproduced independently on Linux with rush-client from main @ 60007c9a8c and RUSH_DAEMON=1:

  1. Non-build commands connect to, and auto-start, the daemon, are rejected, and print a misleading warning. rush-client list with no daemon running takes 2.98 s, compared with 0.98 s for native, because it auto-starts a daemon. Warm, it takes 1.06 s. tab-complete, and repo-defined custom phased or global commands, do the same. Every call prints rush-client: The production daemon requires an explicitly identified native build/rebuild request. Ambiguous custom/rushx requests require --no-daemon.; using in-process Rush. (note the .;). Root cause: routing.ts:9-28 neverDaemonize is a partial deny-list (missing list, tab-complete, init-subspace, install-autoinstaller, update-cloud-credentials, upgrade-interactive, alert, bridge-package, link-package), and repo-defined commands are routed to the daemon (routing.ts:71-80). The daemon then rejects everything except build/rebuild (ProductionDaemonRequestResolver.ts:137-143). Fix: route by an allowlist (build/rebuild, plus install/update when the peer supports them); send everything else in-process without connecting, and show a rejection only in verbose/debug mode.
  2. A TTY with 0 columns hard-fails the build. Under script, docker exec -t before a resize, or agent PTYs created 0x0, process.stdout.columns === 0, and the client exits 1 with Request terminal columns must be a positive safe integer. and no fallback. Native Rush builds fine in the same terminal. Root cause: launchClient.ts:91, :108 pass process.stdout.columns verbatim, and :131 uses ?? 80, which does not catch 0. Fix: treat 0 or undefined as unknown (omit it, or fall back to 80).
  3. Queue-position feedback is suppressed when stderr is not a TTY. AI agents and CI waiting behind another build see 0 bytes for up to 30 s, and then only the wait-timeout failure. TTY clients get waiting for daemon admission (position 1). after about 1 s, repeated even when the position has not changed. Root cause: launchClient.ts:162-168 (onQueuePositionAsync: process.stderr.isTTY ? ... : undefined). The duplicates come from RequestScheduler.ts:304-311. Fix: always write a queue line to stderr (non-TTY: once when queued and on each change), include what the request is waiting for, and de-duplicate unchanged positions.
  4. No immediate feedback while the daemon starts or initializes the graph. The client writes nothing until the daemon streams activity: 3.4-3.9 s of silence on a cold auto-start, 3.6-7.6 s on first graph initialization, and 2.5-4 s for daemon start/restart. Native Rush prints its banner within 0.6-0.8 s. A first line within about 40 ms is achievable (for example rush-client: starting daemon for <workspace>... or connected; preparing graph...).

Repro steps

rush-client daemon stop; time rush-client list                        # 2.98 s + daemon auto-started + warning
script -qefc 'rush-client build --to p01; echo EXIT=$?' /dev/null     # 0x0 PTY -> exit 1
rush-client build & sleep 5; rush-client build --only p03 2>err.txt   # long holder; err.txt is empty for 30 s
rush-client daemon stop; rush-client build 2>&1 | head -1             # first byte only after ~3.7 s

Expected result: Native parity for non-daemon commands. Immediate, TTY-independent feedback for waiting and startup. No hard failure on a 0-column TTY.

Actual result: As described above.

Details

Found during an automated performance/behavior analysis of rush-client/rushd on Linux (the goals were immediate feedback for every terminal action and agent-friendly output). Each item was reproduced by at least two independent runs.

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
Vorherrschende Sprache
TypeScript
Sterne
6.5k
Forks
708
Ø Merge
1 T. 19 Std.
Gemergte PRs (30 T.)
43

Entwicklungsumgebung

Die Einrichtungsdateien dieses Projekts haben wir noch nicht geprüft. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus microsoft/rushstack

Alle Issues in microsoft/rushstack

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.