yarn install sporadically fails with integrity check failure

[kayneb]

Do you want to request a feature or report a bug?
bug

What is the current behavior?
When running yarn install (on our CI) we are finding that random dependencies fail to download due to integrity check failures:

e.g.

yarn install --pure-lockfile error https://registry.yarnpkg.com/react-style-proptype/-/react-style-proptype-3.2.1.tgz: Integrity check failed for "react-style-proptype" (computed integrity doesn't match our records, got "sha512-znIMso2zjWI0V3Ne7hQcOB5HOXdPpJ0HsGw4GBs/uEmVLaN46acxHi5B0PXwOnEzSQ46hp0arB+khsFh/sVIxg==")

If the current behavior is a bug, please provide the steps to reproduce.
Have a somewhat yarn project setup with a somewhat large number of dependencies - keep yarn installing until integrity check fails.

What is the expected behavior?
No integrity checks occur

Please mention your node.js, yarn and operating system version.
node: v10.9.0
yarn: v1.10.0
OS: NixOS (Linux)

This could possibly be occurring due to network failures on our end, but I don't consider this likely considering our build machines are EC2 instances with solid internet connections.

As a workaround for now, we are rolling back to v1.9.4

[arcanis]

As a workaround for now, we are rolling back to v1.9.4

Are you sure this doesn't happen with the 1.9.4? Afaik this is caused by the npm registry sometimes returning 500 at random (the npm client retries until it works, but we don't do this yet), so this should affect all Yarn releases.

[kayneb]

I think integrity checking was added with 1.10.0. See https://github.com/yarnpkg/yarn/pull/5042/files?utf8=%E2%9C%93&diff=unified and https://twitter.com/yarnpkg/status/1037631294170189824

[arcanis]

I know :) But the integrity errors are caused by the registry returning 500 errors that are not properly reported as such.

[Dahaden]

@arcanis We have been testing for flakiness recently, just reverting yarn back to 1.9.4 has taken our builds from a 36% success rate to 88%

[arcanis]

@Dahaden Can you share details regarding the errors? In particular:

• do you use --frozen-lockfile?
• did your lockfile contain the new integrity field, or was it the same one than for the 1.9.4?

The 1.10 ships with the new integrity feature, which requires us to migrate your lockfiles by querying the npm registry for each dependency in order to add the field. If done during CI, it could increase the opportunities for the registry to return an 500 somewhere. If the integrity fields were added before being checked-in, that would alleviate the issue (since the CI wouldn't have to query the network for this anymore) cc @imsnif

If you have the opportunity to retry the 1.10, can you add the following line into a .yarnrc file at the root of your repository? This should prevent Yarn from adding the integrity field if it is missing, which will help us determine if this is the cause of the issue or not.

unsafe-disable-integrity-migration true

[imsnif]

Yeah, as @arcanis said, the migration to 1.10 is more network intensive. If on a flaky network (or if the npm registry is having networking issues at the time) it might explain it. Following.

[arcanis]

This should hopefully be mitigated with #6413

[kayneb]

We did populate the integrity field in the lockfile prior to pushing, so it should be all good.
Awesome thanks for that improvement @arcanis! Will definitely look to bump to 1.11.0, including this fix.

[fqborges]

If you have the opportunity to retry the 1.10, can you add the following line into a .yarnrc file at the root of your repository? This should prevent Yarn from adding the integrity field if it is missing, which will help us determine if this is the cause of the issue or not.

unsafe-disable-integrity-migration true

In my case, this .yarnrc workaround did the job.

[szrenwei]

@Dahaden Can you share details regarding the errors? In particular:

• do you use --frozen-lockfile?
• did your lockfile contain the new integrity field, or was it the same one than for the 1.9.4?

The 1.10 ships with the new integrity feature, which requires us to migrate your lockfiles by querying the npm registry for each dependency in order to add the field. If done during CI, it could increase the opportunities for the registry to return an 500 somewhere. If the integrity fields were added before being checked-in, that would alleviate the issue (since the CI wouldn't have to query the network for this anymore) cc @imsnif

If you have the opportunity to retry the 1.10, can you add the following line into a .yarnrc file at the root of your repository? This should prevent Yarn from adding the integrity field if it is missing, which will help us determine if this is the cause of the issue or not.

unsafe-disable-integrity-migration true

add a .yarnrc file also solved my problem, thanks.

[shunia]

unsafe-disable-integrity-migration true

is working

[viviansteller]

yarn config set unsafe-disable-integrity-migration true -g

[sibelius]

One package that keeps failing the integrity check is this one https://github.com/nodkz/mongodb-memory-server

I hope this helps

[sibelius]

yarn config set unsafe-disable-integrity-migration true -g does not work anymore on version 1.12.3

anyway to fix this? or to disable integrity check?

[arcanis]

That seems strange, we have a CI test that uses it. Can you share the output of yarn config list --verbose ?

[arcanis]

Minus your possible npm auth tokens, of course (we maybe should remove it from the output ...)!

[sibelius]

another strange thing is that if I do the following things:

• [ ] remove yarn.lock
• [ ] run yarn (it will change from sha1 to sha512)
• [ ] remove yarn.lock
• [ ] run yarn (it will change from sha512 to sha1)
• [ ] this will keep happening

config:
jsx yarn config v1.12.3 verbose 0.282 Checking for configuration file "/Users/sibelius/Dev/e/f/f-server/.npmrc". verbose 0.283 Checking for configuration file "/Users/sibelius/.npmrc". verbose 0.283 Found configuration file "/Users/sibelius/.npmrc". verbose 0.284 Checking for configuration file "/usr/local/etc/npmrc". verbose 0.284 Checking for configuration file "/Users/sibelius/Dev/e/f/f-server/.npmrc". verbose 0.285 Checking for configuration file "/Users/sibelius/Dev/e/f/.npmrc". verbose 0.285 Checking for configuration file "/Users/sibelius/Dev/e/.npmrc". verbose 0.285 Checking for configuration file "/Users/sibelius/Dev/.npmrc". verbose 0.285 Checking for configuration file "/Users/sibelius/.npmrc". verbose 0.285 Found configuration file "/Users/sibelius/.npmrc". verbose 0.286 Checking for configuration file "/Users/.npmrc". verbose 0.29 Checking for configuration file "/Users/sibelius/Dev/e/f/f-server/.yarnrc". verbose 0.29 Found configuration file "/Users/sibelius/Dev/e/f/f-server/.yarnrc". verbose 0.29 Checking for configuration file "/Users/sibelius/.yarnrc". verbose 0.29 Found configuration file "/Users/sibelius/.yarnrc". verbose 0.291 Checking for configuration file "/usr/local/etc/yarnrc". verbose 0.291 Checking for configuration file "/Users/sibelius/Dev/e/f/f-server/.yarnrc". verbose 0.291 Found configuration file "/Users/sibelius/Dev/e/f/f-server/.yarnrc". verbose 0.291 Checking for configuration file "/Users/sibelius/Dev/e/f/.yarnrc". verbose 0.291 Found configuration file "/Users/sibelius/Dev/e/f/.yarnrc". verbose 0.292 Checking for configuration file "/Users/sibelius/Dev/e/.yarnrc". verbose 0.292 Checking for configuration file "/Users/sibelius/Dev/.yarnrc". verbose 0.292 Checking for configuration file "/Users/sibelius/.yarnrc". verbose 0.292 Found configuration file "/Users/sibelius/.yarnrc". verbose 0.292 Checking for configuration file "/Users/.yarnrc". verbose 0.301 current time: 2018-11-08T11:36:25.250Z info yarn config { 'version-tag-prefix': 'v', 'version-git-tag': true, 'version-commit-hooks': true, 'version-git-sign': false, 'version-git-message': 'v%s', 'init-version': '1.0.0', 'init-license': 'MIT', 'save-prefix': '^', 'bin-links': true, 'ignore-scripts': false, 'ignore-optional': false, registry: 'https://registry.yarnpkg.com', 'strict-ssl': true, 'user-agent': 'yarn/1.12.3 npm/? node/v10.13.0 darwin x64', lastUpdateCheck: 1541611519487, 'unsafe-disable-integrity-migration': true, 'yarn-offline-mirror': '/Users/sibelius/Dev/e/f/f-server/yarn-offline-cache', 'yarn-offline-mirror-pruning': true, 'experimental-pack-script-packages-in-mirror': true } info npm config { 'init.author.name': 'Sibelius Seraphini', 'init.author.email': '[email protected]', 'init.author.url': 'https://github.com/sibelius', '//registry.npmjs.org/:_authToken': 'blah', progress: true, python: '/usr/bin/python' }

yarn-offline-mirror could be the problem?

[sibelius]

prebuiltVariants keeps changing as well

[sibelius]

here are two prints of what keep happening with mongodb-memory-server

[email protected]:
  version "2.7.0"
  resolved "https://registry.yarnpkg.com/mongodb-memory-server/-/mongodb-memory-server-2.7.0.tgz#663345e8fe38e3b76c703fcc94f691c192fcbd66"
- integrity sha512-T9zBEN3/y7/s4F83B2jAlLHtjjSEp50GQ2J0b7QMbAwM/G7Rkxzdf3cCfzOChDBfI0lQto09EOTdDam6mm0REQ==
+ integrity sha1-M2tbFYi0Q8ExxGJmGySYCdh3/qY=
  dependencies:
    "@babel/runtime" "^7.1.2"
    debug "^4.1.0"

then

[email protected]:
  version "2.7.0"
  resolved "https://registry.yarnpkg.com/mongodb-memory-server/-/mongodb-memory-server-2.7.0.tgz#663345e8fe38e3b76c703fcc94f691c192fcbd66"
-integrity sha512-T9zBEN3/y7/s4F83B2jAlLHtjjSEp50GQ2J0b7QMbAwM/G7Rkxzdf3cCfzOChDBfI0lQto09EOTdDam6mm0REQ==
+integrity sha1-M2tbFYi0Q8ExxGJmGySYCdh3/qY=
  dependencies:
    "@babel/runtime" "^7.1.2"
    debug "^4.1.0"

same machine, same yarn (I'm using 1.12.3 now)

[arcanis]

Hmm - ping @imsnif?

[imsnif]

Thanks for the ping @arcanis!

@sibelius - I cannot reproduce this issue with that package. What I do:

• switch to yarn 1.12.3
• mkdir foo
• cd foo
• yarn init
• yarn add [email protected] ===> the package is populated in yarn.lock with sha512
• rm -rf node_modules
• rm yarn.lock
• yarn ===> still sha512

I repeated this process a few times and still go the same results. A few options:

1. We get the sha512 integrity from the npm registry. There might have been a temporary issue that caused this?
2. Are you perhaps using a private registry proxy? (eg. verdaccio, artifactory etc.?)

If this still happens to you consistently, I'd be very happy to be able to reproduce and debug this. For this I need your help: could you trim an example repo down to the minimum needed to reproduce this consistently (eg. package.json, yarn.lock, yarnrc etc.), make sure it reproduces for you if you move it around (ideally to a different box) and then attach it here?

EDIT: (just to add an explanation)
The package manifest we get from the registry (be it the global npm registry or a private one) includes an integrity field. Some of them are sha512, and some (older ones or ones published with yarn before the integrity patch) are sha1. We use that hash algorithm as the source of truth since we have no choice (if we have sha512 locally and for some reason the repository returns sha1 we have to use sha1 for authentication).
It is conceivable that a package would change from sha512 to sha1 across different versions (eg. if it was published by a different client without sha512 capabilities), but I can't think of a reason for it to happen in the same version. My mind jumps to a registry issue (which would be consistent with the sporadicness of this all) but I have nothing to back this up yet. :)

Thanks for reporting this and helping out. I really want to get to the bottom of these because I've seen them pop up here and there and could never reproduce consistently.

[sibelius]

this is my .yarnrc

yarn-offline-mirror "./yarn-offline-cache"
yarn-offline-mirror-pruning true
experimental-pack-script-packages-in-mirror true

this is happening in a yarn workspaces, I'm gonna try to create a repro

tks for the help

[sibelius]

here is a repro using workspaces

https://github.com/sibelius/yarn-workspaces-mms

check the commits where I change yarn.lock doing the below commands:

• [ ] delete yarn.lock
• [ ] yarn
• [ ] delete yarn lock
• [ ] yarn

[imsnif]

The only diff I'm getting is this:

--- a/yarn.lock
+++ b/yarn.lock
@@ -721,7 +721,7 @@ [email protected]:
     tmp "^0.0.33"
     uuid "^3.2.1"
   prebuiltVariants:
-    mongodb-memory-server-v2.7.0-darwin-x64-64 d5c108b5d7e74032ed4f62b3ec5dc9568b8b0e3b
+    mongodb-memory-server-v2.7.0-linux-x64-64 edf91278f9941e8d2fbd47bf203ec21af50fdb8c

which is not ideal, but out of scope for now. :)

How often does this happen to? I tried 3-4 times and everything stays a-ok.

[sibelius]

sha1 -> sha512 https://github.com/sibelius/yarn-workspaces-mms/commit/d41d4633c6b7726cdbb0760cbf10b3d47ba8eaa7
sha512 -> sha1 https://github.com/sibelius/yarn-workspaces-mms/commit/32fa566d10b5603f03f60febced4d01640dd3ff0

[imsnif]

For sure. I just need to be able to reproduce it, otherwise I'm just guessing. Does it happen to you every time with this repo?

[sibelius]

not every yarn install, try to delete node_modules and yarn.lock and try to do yarn again

this is my mac os x version 10.14.1, not sure if this helps or not

node v10.12.0, using nvm 0.31.1

[imsnif]

I've now run it 10 times and no reproduction. I'd really like to check and see if you're getting a different response from the registry for some reason. If you have the jq json parser, would you mind running this command a few times and seeing if you sometimes get sha1 returned?

curl --silent https://registry.yarnpkg.com/mongodb-memory-server/ | jq '.versions."2.7.0".dist.integrity'

BTW - I assume you don't start out with the local cache folder, right?

[sibelius]

it keeps returning sha512

I think the problem is with the offline cache, I've disabled this for now

and it keeps on sha512

I've used the cache because native packages always recompiled, but this is another issue

[imsnif]

Hey @sibelius, that's quite interesting. If you delete the offline cache and then re-enable it, does the issue reoccur?

[sibelius]

I have many .yarnrc in a lot of different folders, because I work in a lot of different projects

I've deleted all of them, and for now, it is working fine

not sure if this was a problem with some old yarn-offline-cache folder

[imsnif]

Alright, so the problematic path seems to be here: https://github.com/yarnpkg/yarn/blob/master/src/resolvers/registries/npm-resolver.js#L170

I'm guessing (all I can do right now unfortunately*) that we go to the offline mirror to get the integrity from there, we get the old sha1 integrity and are satisfied with it and thus yarn.lock is updated with the old sha1. What I'm not fully understanding is why this happens sporadically. If this is the case, why is the offline mirror bypassed every now and then. @arcanis - do you have any ideas?

I wouldn't want to solve this by always going to the registry to get the integrity for obvious reasons - but I would love to solve the flakiness here as soon as we understand it better.

*This might theoretically be reproducible by starting an offline mirror, artificially creating a manifest that has only sha1 integrity and running this a few times. If there aren't any ideas, I'll try to get to that soon.

[sibelius]

can we do not update yarn.lock when resolving from offline cache?

[imsnif]

@sibelius - perhaps, but I'd first like to make sure this is indeed the issue before we implement the solution.

[aprilandjan]

Encounter this problems with yarn v1.12.3 when trying to yarn a project provided by private registry. Tried unsafe-disable-integrity-migration true but no luck.

I had to use yvm and manually install previous versions of yarn and found that the version v1.10.1 solved my issue:

yvm install 1.10.1
yvm exec 1.10.1 install/add

[Axure]

It could happen when you are using yarn local cache with the yarn registry set to a 3rd party mirror which does not yet provide the integrity field, e.g. the taobao mirror https://registry.npm.taobao.org.

[glensc]

I'm having similar sporadical fails, when using offline and verdaccio registry proxy.

in fact, if i repeat the cycle, i still end up with error on accepts-1.3.5.tgz:

$ yarn cache clean
$ rm -rf node_modules/ npm-packages-offline-cache/
$ yarn install --update-checksums
...

$ rm -rf node_modules/ npm-packages-offline-cache/
$ yarn cache clean
...
$ yarn
yarn install v1.13.0
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
error https://npm.example.net/@types%2faccepts/-/accepts-1.3.5.tgz: Integrity check failed for "@types/accepts" (computed integrity doesn't match our records, got "sha512-z4PhNX7vuL3xVChQ1m2AB9Yg5AULVxXcg/SpIdNs6c5H0NE8XYXysP+DGNKHfuwvY7kxvUdBeoGlODJ6+SfaPg==")
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

and yarn.lock is updated for some random packages, but not accepts-1.3.5.tgz

btw, if i have the accepts-1.3.5.tgz tarball, how to build that sha512 checksum in that encoding thats used in lockfile?

[glensc]

more fun, is that if i retry the same command, it passes, and the calculated integrity also changes

error https://npm.example.net/@types%2faccepts/-/accepts-1.3.5.tgz: Integrity check failed for "@types/accepts" (computed integrity doesn't match our records, got "sha512-z4PhNX7vuL3xVChQ1m2AB9Yg5AULVxXcg/SpIdNs6c5H0NE8XYXysP+DGNKHfuwvY7kxvUdBeoGlODJ6+SfaPg==")
error https://npm.example.net/@types%2faccepts/-/accepts-1.3.5.tgz: Integrity check failed for "@types/accepts" (computed integrity doesn't match our records, got "sha512-pt4oTticGUEOZCvli0I7ekmpXopaX+Xvb/TQRaTKnvZNIH9Srs0VWi2NGBfsRscAgwtIEtxW5JOB9sI0oN3cjw==")

$ yarn cache clean; rm -rf node_modules/ npm-packages-offline-cache/; yarn
yarn cache v1.13.0
success Cleared cache.
✨  Done in 4.27s.
yarn install v1.13.0
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
error https://npm.example.net/@types%2faccepts/-/accepts-1.3.5.tgz: Integrity check failed for "@types/accepts" (computed integrity doesn't match our records, got "sha512-z4PhNX7vuL3xVChQ1m2AB9Yg5AULVxXcg/SpIdNs6c5H0NE8XYXysP+DGNKHfuwvY7kxvUdBeoGlODJ6+SfaPg==")
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
$ yarn cache clean; rm -rf node_modules/ npm-packages-offline-cache/; yarn
yarn cache v1.13.0
success Cleared cache.
✨  Done in 4.66s.
yarn install v1.13.0
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
[3/4] 🔗  Linking dependencies...
...
[4/4] 🔨  Building fresh packages...
✨  Done in 52.62s.
$

[Axure]

@glensc This problem seems to have been fixed by https://github.com/yarnpkg/yarn/pull/7499

[rosskevin]

7499 did not work for me, I manually updated to 1.18.0 (should include this pr) and I am still seeing this when hitting the github package registry (GPR).

[2/4] 🚚  Fetching packages...
error https://npm.pkg.github.com/download/@alienfast/i18next-loader/1.1.0/215f48fb0d26ca943010d6b7c053ec56056e6b708bf34090c135d4655fc41af6: Integrity checked failed for "@alienfast/i18next-loader" (none of the specified algorithms are supported)
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
~/p/tools ❯❯❯ yarn --version                                                                                                                                                                                                       ✘ 1 
1.18.0

I am unsure if my problem is actually specific to GPR or the same as this issue.

EDIT: yarn --update-checksums seems to have worked, even though I cleaned cache and local on previous attempts.

[ttupper92618]

^^^ Joining the chorus: We've had huge problems with integrity check failures, and socket connection failures, on 1.19.0. Dropping our pipelines back to 1.18.0 resolves the issues.

[rocketraman]

Having this issue with yarn 1.19.0 as well. The sequence is like this:

1) Get integrity check failure on yarn install:

error Integrity check failed for "dtrace-provider" (computed integrity doesn't match our records, got "sha1-GuESZrZN9QNPNXqrQHeU3m0qTRM=")
error Integrity check failed for "protobufjs" (computed integrity doesn't match our records, got "sha1-SCXGqgFaGWVGcUSLhvTIKSt3tss=")

2) rm -fr node_modules yarn-offline-cache && yarn cache clean (the latter command, BTW, is ridiculously slow and brings my Linux box to its knees until it is finished, even with ionice -c3).

3) Yay! It works.

4) Some indeterminate amount of time later (with no changes in yarn.lock or package.json), get the integrity check failure again. Boo! It doesn't work. Go to Jail (i.e. step 1), do not pass Go, do not collect $200. Argh.

The same error is happening on my Linux box, my buddies WSL 1 environment, and on our Linux CI servers, so its not something specific to my machine.

Artifacts are resolved from our private npm repository using Nexus.

I've even erased and updated our yarn.lock in between step 2 and 3, but it doesn't break the cycle.

These problems all seemed to start around the time we added a yarn-offline-mirror, but we also updated yarn around the same time. Next time it happens I'll try disabling the offline mirror and see if that fixes the integrity error.

[rocketraman]

These problems all seemed to start around the time we added a yarn-offline-mirror, but we also updated yarn around the same time. Next time it happens I'll try disabling the offline mirror and see if that fixes the integrity error.

Happened again, and commenting the offline mirror lines from .yarnrc fixed the problem without deleting node_modules and without yarn cache clean.

So at least in my case, the yarn offline cache is the culprit here. Deleting it and recreating it only solves the problem temporarily.

[rocketraman]

Also, install --force does not fix the problem, even thoug AIUI that is supposed to ignore caches.

[unfor19]

yarn v1.19.1
Following @rosskevin reply, I've tried yarn --update-checksums before running yarn install, and it works like a charm

pre_build:
  commands:
    - echo ">> installing dependencies"
    - yarn --update-checksums # Update checksums in the yarn.lock lockfile if there’s a mismatch between them and their package’s checksum.
    - yarn install
    - yarn lint
    - yarn tsc
    - yarn test

[rocketraman]

--update-checksums does not work for me. Well, to clarify, it reports "success Already up-to-date", but yarn upgrade file:../other-package still fails if I have the yarn-offline-mirror enabled.

[robclancy]

This is super frustrating. I do lots of things, and randomly it will work.

[snowyu]

Why not use the SHA512 and the old sha1 both together to avoid this?

[PeterRock]

It happend for there are multiple registry domains in my lock file.
So, I remove them, keep only one domain (in resolved prop).
The reason is the repos use different path for files, you can see here