[rush] rushd: warm daemon reports a successful no-op build after an operation's output folders were deleted, leaving the outputs missing
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 45/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- nodejs, shell, typescript
- 领域
- build-system, tooling
调研方向
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.
由索引模型根据 Issue 内容生成。
描述
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 |
- 主要语言
- TypeScript
- 星标
- 6.5k
- 派生
- 708
- 平均合并
- 1 天 19 小时
- 30 天内合并 PR
- 43
环境准备
我们还没有检查这个项目的环境配置文件。先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
microsoft/rushstack 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
microsoft/rushstack#5971 · 2 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 65/100
microsoft/rushstack#5902 · 1 个 reaction ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
microsoft/rushstack#5839 · 1 个 reaction ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 70/100
microsoft/rushstack#5683 · 3 条评论 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 45/100
维护者通常 1 天内回复
查看 microsoft/rushstack 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 68/100
microsoft/vscode-livepreview#876 ·
维护者通常 1 天内回复
-
needs-triage
难度 1/5 1 小时以内 新手友好度 90/100
JustJarethB/invoicer#54 ·
-
ICP 1.2.0 shows a scheduled task's interval in milliseconds under the label "Interval (In seconds)"未关闭Needs Triage Type/Bug
难度 2/5 1-3 小时 新手友好度 68/100
wso2/product-integrator#2585 ·
维护者通常 1 天内回复
-
check:passed streams:add
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复
-
design
难度 2/5 1-3 小时 新手友好度 72/100
MTES-MCT/monitor-field#119 ·
维护者通常 1 天内回复