Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Fechada
  • Algo errado?
#6,058 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
45/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
nodejs, shell, typescript
Domínio
build-system, tooling

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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
Linguagem predominante
TypeScript
Estrelas
6.5k
Forks
708
Merge médio
4d 7h
PRs com merge (30d)
61

Preparar o ambiente

Ainda não verificamos os arquivos de configuração deste projeto. Comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de microsoft/rushstack

Todas as issues de microsoft/rushstack

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.