host registry.npmjs.org is now offline and results in 500 internal server error

Thanks for the package. I am using Verdaccio v4.0.0 in production environment and lately starting to get 500 server error for some requests which eventually results in failed cli commands.

Below given is my configuration

storage: /verdaccio/storage
auth:
  htpasswd:
    file: /verdaccio/conf/htpasswd
    max_users: -1
uplinks:
  npmjs:
    url: https://registry.npmjs.org/
packages:
  '@*/*':
    access: $authenticated
    publish: deployer
    proxy: npmjs
  '**':
    access: $authenticated
    publish: deployer
    proxy: npmjs
middlewares:
  audit:
    enabled: true
logs:
  - {type: stdout, format: pretty, level: trace}

Steps to reproduce

• create a npm project with .npmrc in which registry points to registry=http://private_registry.com
• run npm install

Client logs

npm verb type Error
npm verb stack Error: 500 Internal Server Error: multer@http://private_registry.com/multer/-/multer-1.4.2.tgz
npm verb stack     at fetch.then.res (/Users/apple/.nvm/versions/node/v8.9.1/lib/node_modules/npm/node_modules/pacote/lib/fetchers/registry/fetch.js:42:19)
npm verb stack     at tryCatcher (/Users/apple/.nvm/versions/node/v8.9.1/lib/node_modules/npm/node_modules/bluebird/js/release/util.js:16:23)
npm verb stack     at Promise._settlePromiseFromHandler (/Users/apple/.nvm/versions/node/v8.9.1/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:512:31)
npm verb stack     at Promise._settlePromise (/Users/apple/.nvm/versions/node/v8.9.1/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:569:18)
npm verb stack     at Promise._settlePromise0 (/Users/apple/.nvm/versions/node/v8.9.1/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:614:10)
npm verb stack     at Promise._settlePromises (/Users/apple/.nvm/versions/node/v8.9.1/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:693:18)
npm verb stack     at Async._drainQueue (/Users/apple/.nvm/versions/node/v8.9.1/lib/node_modules/npm/node_modules/bluebird/js/release/async.js:133:16)
npm verb stack     at Async._drainQueues (/Users/apple/.nvm/versions/node/v8.9.1/lib/node_modules/npm/node_modules/bluebird/js/release/async.js:143:10)
npm verb stack     at Immediate.Async.drainQueues (/Users/apple/.nvm/versions/node/v8.9.1/lib/node_modules/npm/node_modules/bluebird/js/release/async.js:17:14)
npm verb stack     at runCallback (timers.js:789:20)
npm verb stack     at tryOnImmediate (timers.js:751:5)
npm verb stack     at processImmediate [as _immediateCallback] (timers.js:722:5)
npm verb cwd /Users/apple/Documents/Chat-Bot
npm verb Darwin 19.3.0
npm verb argv "/Users/apple/.nvm/versions/node/v8.9.1/bin/node" "/Users/apple/.nvm/versions/node/v8.9.1/bin/npm" "i" "--verbose"
npm verb node v8.9.1
npm verb npm  v5.5.1
npm ERR! code E500
npm ERR! 500 Internal Server Error: multer@http://private_registry.com/multer/-/multer-1.4.2.tgz
npm verb exit [ 1, true ]

Verdaccio Server Logs

info <-- 192.168.192.1 requested 'GET /multer/-/multer-1.4.2.tgz'
trace--- api middleware using legacy auth token
trace--- authenticating developer
trace--- authentication for user developer was successfully. Groups: [ 'developer' ]
trace--- allow access for multer
trace--- allowed access for multer
info --> making request: 'GET https://registry.npmjs.org/multer/-/multer-1.4.2.tgz'
error--- unexpected error: ETIMEDOUT
Error: ETIMEDOUT
   at Timeout._onTimeout (/opt/verdaccio/node_modules/request/request.js:845:19)
   at ontimeout (timers.js:436:11)
   at tryOnTimeout (timers.js:300:5)
   at listOnTimeout (timers.js:263:5)
   at Timer.processTimers (timers.js:223:10)
http <-- 500, user: developer(106.51.78.222 via 192.168.192.1), req: 'GET /multer/-/multer-1.4.2.tgz', error: internal server error
warn --> host registry.npmjs.org is now offline

[raghavgarg1257]

@juanpicado thanks for the reply. I am working with @anshratn1997 and will be taking over the communication on his behalf.

I understand the expected behavior of making uplink offline if it is failing frequently, but is it expected for registry.npmjs.org to fail?

The tarball was not present in the storage at the time, but however I think the client’s npm itself generates the request again for the failed modules and then eventually it got resolved after which I can see that particular tarball in storage.

I also tried playing around with setting max_fails which is by default 2 and made it 20 and that’s when the client’s npm command is getting resolved eventually(after many retries).

Please let me know in case you need any other information from our side. Adding our machine specs in case that makes it any easier to track down this issue.

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.3 LTS
Release:	16.04
Codename:	xenial

$ docker --version
Docker version 19.03.5, build 633a0ea838

$ cat docker-compose.yml 
version: '3.1'

services:
  verdaccio_v4:
    image: verdaccio/verdaccio:4.0.0
    container_name: verdaccio_v4
    restart: always
    ports:
      - 4874:4873
    volumes:
      - "./storage:/verdaccio/storage"
      - "./conf:/verdaccio/conf"
volumes:
  verdaccio:
    driver: local

Also, a suggestion, should we add the timestamp as well in the logs, in order to understand the time difference between the request to uplink and getting a response/error from it? I would be happy to raise a PR if that’s something you agree with.

[juanpicado]

hi folks, to clarify concerns about this, as @raghavgarg1257 described a valid approach is increasing max_fails and even fail_timeout. The client is the one that retries several times and verdaccio just allow 2 failures before return 500.

uplinks:
  npmjs:
    url: https://registry.npmjs.org/
    max_fails: 20
    fail_timeout: 10m

This configuration will avoid the message warn --> host registry.npmjs.org is now offline but I guess nobody wants to retry if npmjs is completely down and you don’t have all you need already cached.

I think there is nothing else to answer here, I close it.