Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Fermée
  • Quelque chose ne va pas ?
#6,058 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
45/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
nodejs, shell, typescript
Domaine
build-system, tooling

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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
Langage dominant
TypeScript
Étoiles
6.5k
Forks
708
Merge moyen
4 j 7 h
PR mergées (30 j)
61

Préparer son environnement

Nous n'avons pas encore vérifié les fichiers d'installation de ce projet. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de microsoft/rushstack

Toutes les issues de microsoft/rushstack

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.