verdaccio: NPM pulls corrupted packages from Verdaccio instance (its back)

Same behavior as reported in ticket #756 but those fixes dont fix the issue. I am doing this with a fairly generic Angular 6 cli built project. Error output from a manually issued npm install --verbose:

npm timing audit body Completed in 94ms
npm WARN tarball tarball data for typescript@>=2.6.2 <2.8 (sha512-p5TCYZDAO0m4G344hD+wx/LATebLWZNkkh2asWUFqSsD2OrDNhbAHuSjobrmsUmdzjJjEeZVU9g1h3O6vpstnw==) seems to be corrupted. Trying one more time.
npm WARN tarball tarball data for typescript@~2.9.1 (sha512-Gr4p6nFNaoufRIY4NMdpQRNmgxVIGMs4Fcu/ujdYk3nAZqk7supzBE9idmvfZIlH/Cuj//dvi+019qEue9lV0w==) seems to be corrupted. Trying one more time.
npm WARN tarball tarball data for typescript@~2.8.0 (sha512-IIU5cN1mR5J3z9jjdESJbnxikTrEz3lzAw/D0Tf45jHpBp55nY31UkUvmVHoffCfKHTqJs3fCLPDxknQTTFegQ==) seems to be corrupted. Trying one more time.
npm WARN tarball tarball data for @angular/compiler@6.1.10 (sha512-FPIb2j3zfoBwb6vo/u0gQeu70h8InGlSisBr3xMACs/35/pwB6kbQR+JQiUr0D7k6QApg7AuMkvq8aFNelg0aw==) seems to be corrupted. Trying one more time.

Note I had this behavior with Verdaccio 3, did one of the recommendations in the #756 ticket and restarted my Docker Verdaccio container which upgraded it to Verdaccio 4 (thanks for all of the help you provided in #1324 to get that working) and I now have the exact same behavior with Verdaccio 4.01.

I have purged the node_modules and package-lock.json (and as I just rebuilt my packages tree in the new Docker instance I know those are clean). I have done the npm cache purge commands listed in 756 and I still get the same behavior.

Odd notes - this only happens on my build server, even when it is setup to wipe the directory and clean build - on my development vm the npm install works fine, so it seems to be something related to that machine but I am not sure what it could be. In both cases I am currently manually running the commands under my user account, so it is not like they are running under different security.

On machine that works npm info using npm@6.5.0 npm info using node@v10.14.2

on machine with issue npm info using npm@6.8.0 npm info using node@v10.14.2

Any ideas/suggestions on where to look for this? I guess I can try updating the working machine to npm 6.8 to see if it then stops working…

Update - well, going to 6.8.0 on the working machine didnt break it, and going to 6.9.0 on the broken machine didnt fix it so I am open to suggestions on things to try.

Update 2 - well, I did a npm cache verify and then an npm update still without success, but the end of the log from the Verdaccio server is interesting:

 http <-- 200, user: null(172.16.121.185), req: 'GET /has-values', bytes: 0/4129
 http --> 304, req: 'GET https://registry.npmjs.org/copy-descriptor' (streaming)
 http --> 304, req: 'GET https://registry.npmjs.org/copy-descriptor', bytes: 0/0
 http <-- 200, user: null(172.16.121.185), req: 'GET /copy-descriptor', bytes: 0/2400
 http <-- 200, user: null(172.16.121.185), req: 'POST /-/npm/v1/security/audits/quick', bytes: 74646/1172
 http <-- 200, user: null(172.16.121.185), req: 'GET /typescript/-/typescript-2.7.2.tgz', bytes: 0/6076378
 http <-- 200, user: null(172.16.121.185), req: 'GET /typescript/-/typescript-2.9.2.tgz', bytes: 0/6372426
 http <-- 200, user: null(172.16.121.185), req: 'GET /typescript/-/typescript-2.8.4.tgz', bytes: 0/6034070
 http <-- 200, user: null(172.16.121.185), req: 'GET /@angular%2fcompiler/-/compiler-6.1.10.tgz', bytes: 0/5429592
 http <-- 200, user: null(172.16.121.185), req: 'GET /@angular%2fcompiler/-/compiler-6.1.10.tgz', bytes: 0/5429592
 http <-- 200, user: null(172.16.121.185), req: 'GET /typescript/-/typescript-2.9.2.tgz', bytes: 0/6372426
 http <-- 200, user: null(172.16.121.185), req: 'GET /typescript/-/typescript-2.7.2.tgz', bytes: 0/6076378
 http <-- 200, user: null(172.16.121.185), req: 'GET /performance-now/-/performance-now-2.1.0.tgz', bytes: 0/4564
 http <-- 200, user: null(172.16.121.185), req: 'GET /postcss/-/postcss-6.0.23.tgz', bytes: 0/183627
 http <-- 200, user: null(172.16.121.185), req: 'GET /uri-js/-/uri-js-3.0.2.tgz', bytes: 0/107604
 http <-- 200, user: null(172.16.121.185), req: 'GET /selenium-webdriver/-/selenium-webdriver-3.6.0.tgz', bytes: 0/776120
 http <-- 200, user: null(172.16.121.185), req: 'GET /resolve/-/resolve-1.11.0.tgz', bytes: 0/33459
 http <-- 200, user: null(172.16.121.185), req: 'GET /less/-/less-3.9.0.tgz', bytes: 0/671112
 http <-- 200, user: null(172.16.121.185), req: 'GET /typescript/-/typescript-2.8.4.tgz', bytes: 0/6034070
 http <-- 200, user: null(172.16.121.185), req: 'GET /less/-/less-3.9.0.tgz', bytes: 0/671112

as mentioned in the other ticket, the problem file seem to be larger ones.

Update 3 - I tried to disable to the caching of npmjs packages to no effect (even after doing a npm cache verify on the machine in question before redoing the npm install). Is this the right spot to put in the cache false setting?

`# a list of other known repositories we can talk to
uplinks:
  npmjs:
    url: https://registry.npmjs.org/
    cache: false

`

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 3
  • Comments: 20 (3 by maintainers)

Most upvoted comments

Set server.keepAliveTimeout in config to a large value works for me (or with the new version 4.0.4, set it to zero also works)