[rush] Operation Build Cache Log Restoration collision
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- typescript
- Domain
- build-system
Research direction
Start with libraries/rush-lib/src/logic/operations/OperationMetadataManager.ts at the linked location, then reproduce the collision by running the same cacheable operation with different parameters in parallel and rerunning the build. Compare the restored logs for each shard; done means each independent run restores its own logs rather than the logs from another shard.
Written by the indexing model from the issue text.
Description
Summary
Operation Build Cache Log Restoration collision when multiple of same operation with different parameters run in parallel on same filesystem.
We are trying to run multiple of the same operation with different parameters on the same CI agent (for example, rush test:integration--shard=1 --shard-total=3, rush test:integration--shard=2 --shard-total=3, rush test:integration--shard=3 --shard-total=3). We do this to parallelize our tests and take advance of build caching.
This all works, but when restoring from cache, even despite the unique cache keys, the restored logs are all for one of the three shards.
Repro steps
- Have an operation with custom parameters on command-line, configured as build-cacheable
- Run multiple of that same operation, with different parameters passed on the same build agent in parallel
- Re run the build
Expected result:
Restored logs for each of the three independent runs
Actual result:
All three runs have restored logs for just one of the initially passing runs.
Details
I'm fairly certain the problem is here:
https://github.com/microsoft/rushstack/blob/main/libraries/rush-lib/src/logic/operations/OperationMetadataManager.ts#L66
The location on the filesystem is not unique per parameter, only per operation. (This despite the fact that the build cache is in fact parameter aware.
Standard questions
Please answer these questions to help us investigate your issue more quickly:
| Question | Answer |
|---|---|
@microsoft/rush globally installed version? |
5.155.0 |
rushVersion from rush.json? |
5.155.0 |
pnpmVersion, npmVersion, or yarnVersion from rush.json? |
[email protected] |
(if pnpm) useWorkspaces from pnpm-config.json? |
no |
| Operating system? | Linux |
| Would you consider contributing a PR? | Yes, but would need guidance, I don't see how to fix this |
Node.js version (node -v)? |
22.11.1 |
- Dominant language
- TypeScript
- Stars
- 6.5k
- Forks
- 708
- Avg merge
- 4d 13h
- Merged PRs (30d)
- 62
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/rushstack
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
All issues in microsoft/rushstack
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
bcgov/bc-wallet-mobile#4761 · 1 comment ·
-
external-issue to-triage
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
area-deployment area-integrations triage:bot-seen
Difficulty 2/5 Half a day Newbie friendliness 86/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
refactor
Difficulty 2/5 1-3 hours Newbie friendliness 84/100