[rush] "local" cache id is different for the same package on two different systems

[kgetz-arista]

Summary

The "local" cache id is not computed deterministically (or possibly has a dependency on the underlying OS being used).

Repro steps

1. git clone a package on Windows 11
2. git clone the same package on Debian 9
3. Run rush build with --debug-build-cache-ids

Expected result: The cache ids should be the same

Actual result: The cache ids for the package are different because the "local" cache id is different:

97c97
< |local=7ab5ffa838014a433ddbadde704677bb453a1471
---
> |local=7b7726d01ff9f111b644c59aae6e8684fe87bae0
99c99
< Result: ccb217ffd1553947c43ec8c06c05cd3a779ed269
---
> Result: 08a35644c5992ce164e02fd6a1fca9e34d946f63

Details

Is there a way to get a more nuanced breakdown of hashes within the "local" cache id, so we can figure out what's different?

Standard questions

Please answer these questions to help us investigate your issue more quickly:

Question	Answer
@microsoft/rush globally installed version?	5.157.0
rushVersion from rush.json?	5.157.0
Operating system?	Windows 11, Linux
Would you consider contributing a PR?	No
Node.js version (node -v)?	22.14.0

[dmichon-msft]

There is not nearly enough information in this issue for this to be actionable. The "local" component of the state hash is affected by:

1. Any environment variables specified in dependsOnEnvVars in rush-project.json (is this setting used in your repo?)
2. Any additional files specified in dependsOnAdditionalFiles in rush-project.json (is this setting used in your repo?)
3. The set of file content hashes returned by Git for tracked files located within the folder. Compare the output of git ls-files --cached --format="%(objectname) %(path)" in the project folder on both operating systems.
4. The content hash of the .rush/temp/shrinkwrap-deps.json in the current project folder. Compare the output of git hash-object ./.rush/temp/shrinkwrap-deps.json in the project folder on both operating systems.

[kgetz-arista]

There is not nearly enough information in this issue for this to be actionable.

I agree, and I apologize about that. This issue has been noticed by several members of our team, but it's very random and non-deterministic, which has made it hard to debug. The info you gave above is super helpful - the next time I personally see this happening, I can drill down into those four areas and figure out exactly what is different. Thanks for the info! Hopefully the next time I comment here, I'll have some more useful details.

[kgetz-arista]

@dmichon-msft @iclanton My coworker and I each ran into this again in the last two weeks, but we're happy to report that the debugging information above was super helpful. It turns out it was the .rush/temp/shrinkwrap-deps.json file in both of our cases. We had each updated our local repo via git pull but had not run rush install, and that was causing the shrinkwrap file to have a different hash. After running rush install the content hashes were identical and Rush pulled from the cache correctly. 🎉

At this point, I think the mystery has been solved, so feel free to close this.