Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[rush] rushd: warm daemon reports a successful no-op build after an operation's output folders were deleted, leaving the outputs missing

Chiusa
  • Qualcosa non va?
#6,058 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
nodejs, shell, typescript
Ambito
build-system, tooling

Direzione di ricerca

The issue is in the daemon's operation invalidation logic. Start by examining PhasedOperationPlugin.ts:139 (shouldEnableOperation) and WorkspaceEngineComponentFactory.ts:273-286. Understand how output fingerprints are currently ignored. The fix involves recording a fingerprint of declared output folders after a successful operation and invalidating when this changes. Run the existing rush-daemon tests to verify changes.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

A warm daemon treats an operation as up to date by comparing only its input state hashes with the retained in-memory result. Build outputs are git-ignored and are not part of any hash, and output-folder changes are never mapped to invalidations. After rm -rf <project>/lib, git clean -xdf or heft clean, the next rush-client build (even --to <that project>) exits 0, runs 0 operations, prints nothing, and leaves the outputs missing. Native rush build restores them from the build cache.

Repro steps

# any workspace, RUSH_DAEMON=1, rush-client from main @ 60007c9a8c, one shell
rush-client build; rush-client build        # warm
rm -rf packages/p03/lib
rush-client build                           # exit 0, 0 ops, 0 bytes
rush-client build --to p03                  # exit 0, 0 ops, 0 bytes
ls packages/p03/lib                         # still missing
rush build --to p03                         # native: restores p01..p03 from cache, lib is back

Expected result: Missing or changed declared outputs (outputFolderNames) invalidate the operation, so it is re-restored from cache or re-executed, and "SKIPPED because already built" always means the outputs exist.

Actual result: The daemon reports success while the workspace is broken. Downstream consumers and tests later fail with confusing errors.

Details

Root cause (main @ 60007c9a8c): the warm skip (PhasedOperationPlugin.ts:139, shouldEnableOperation) compares input hashes only. WorkspaceEngineComponentFactory.ts:273-286 invalidates only hash-changed operations. ProductionDaemonRequestResolver getChangedOperations compares own-state hashes, which ignore outputs. The session watcher does not map output-folder events to invalidations. Only the "dirty native lock" case is guarded (PhasedCommandEngineExecution.ts:36).

Suggested fix: when an operation completes successfully, record a cheap fingerprint of its declared output folders (existence plus directory identity/mtime, or the file list and sizes the cache plugin already computes). During reconciliation, invalidate any retained operation whose output fingerprint changed or is missing. A prototype of this approach invalidated exactly the affected operation (1 cache restore, dependents untouched, no false positives) and passed the existing rush-daemon tests.

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

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
Lingua principale
TypeScript
Stelle
6.5k
Fork
708
Merge medio
4g 7h
PR unite (30g)
61

Preparare l'ambiente

Non abbiamo ancora controllato i file di configurazione di questo progetto. Parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di microsoft/rushstack

Tutte le issue di microsoft/rushstack

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.