[rush] "rush update" does not recover from ERR_PNPM_TARBALL_INTEGRITY #3777
Labels
bug
Something isn't working as intended
effort: easy
Probably a quick fix. Want to contribute? :-)
help wanted
If you're looking to contribute, this issue is a good place to start!
Projects
Summary
If an NPM version is republished with a different tarball hash, then PNPM correctly detects this and reports
ERR_PNPM_TARBALL_INTEGRITY
. Howeverrush update
does not handle it correctly; it waits for 1 minute and then ignores the problem. The lockfile can only be repaired by usingrush update --full
.This seems like a bug. Invoking
rush update
should repair the lockfile.Repro steps
This repro relies on republishing a tarball to Verdaccio. A simpler repro is possible, but it's useful to show how this problem arose in real life.
1. Shell window A: Start the Verdaccio service
"lockfile-explorer-demos" folder, "main" branch
2. Shell window B: Publish the test package
"lockfile-explorer-demos" folder, "main" branch
3. Shell window C: Install the test package
"lockfile-explorer-demos-checkout" folder, "demo/sbs-0" branch
4. Shell window A: Modify the test package
"lockfile-explorer-demos" folder, "main" branch
5. Shell window B: Republish the test package
"lockfile-explorer-demos" folder, "main" branch
6. Shell window C: Try installing again
"lockfile-explorer-demos-checkout" folder, "demo/sbs-0" branch
Final state
rush update
takes a very long time to complete (because of the "1 minute" delay):Afterwards it claims to have succeeded (
Rush update finished successfully.
) and runningrush install
will finish immediately in a green state. However thecommon/config/rush/pnpm-lock.yaml
file is NOT updated. If you runrush purge
, thenrush update
will fail again.rush update --full
does fix the problem.Details
Using Process Monitor to trace the kernel calls, I was able to determine that the cached state is being read from this location:
C:\Users\Owner\AppData\Local\pnpm-cache\metadata\localhost+54321\
At first I mistakenly thought that this was the cause, however I later determined that it is unrelated. Similar to the
--store
parameter, maybe we should use --cache-dir to isolate this state?Standard questions
Please answer these questions to help us investigate your issue more quickly:
@microsoft/rush
globally installed version?rushVersion
from rush.json?useWorkspaces
from rush.json?node -v
)?The text was updated successfully, but these errors were encountered: