npm Community Forum (Archive)

The npm community forum has been discontinued.

To discuss usage of npm, visit the GitHub Support Community.

ENOAUDIT from registry.npmjs.org (503)

The npm audit error keeps appearing. Is seems to be working fine in 50% cases.


Cannot get anything back from npm audit other than:

ENOAUDIT Your configured registry (https://registry.npmjs.org/) does not support audit requests, or the audit endpoint is temporarily unavailable.


95% of failed pipelines because of this in the last 24 hours for some of our projects that include huge lockfiles.
It looks like that fix mentioned in the status page made it much worse.


I am likewise encountering the same error intermittently, the majority of the time, on CI builds. Would love an update!


Any updates on this issue?


There was an outage again this morning, for at least twenty minutes.


Same here, get failed frequently via circleci builds


https://status.npmjs.org/incidents/1jdmllbx0q59


Nonstop this morning. It’d be great to get another update on this.


Thank you for the confirmation! We appreciate the feedback and glad to know the recent changes have helped!


This is causing a large number of pipelines for my team and my customers teams to fail on a CONSTANT basis. Please help resolve this!


Have seen this error happening on CI/CD and locally on and off a little while now. yesterday (13/05/2019) however we saw this error on 4 out 5 builds causing many failures.

Are there any updates from the NPM team on this issue?


Also seeing this issue in our pipeline, breaking builds.
Getting 503s with the following:
{
body: { message: ‘No frontdoor hosts available’ },
message: ‘503 No backends available - POST https://registry.npmjs.org/-/npm/v1/security/audits
}


Same problem. Any updates?

info using npm@6.9.0
info using node@v12.4.0

http fetch POST 503 https://registry.npmjs.org/-/npm/v1/security/audits 14254ms


This still happens unfortunately. The 503 is coming from CloudFlare with the error message:
“message”: “No frontdoor hosts available”.

any updates?


Can confirm I am seeing the npm ERR! code ENOAUDIT again :slightly_frowning_face:.

5 of 20 npm audit runs resulted in this error.


Also facing this issue on a consistent basis…


This problem gets worse month by month. Today was especially bad.


New capacity was added to the service and we are continuing to monitor for any further issues

(back in January) https://status.npmjs.org/incidents/vnmt8kf52bh4

More capacity has been added to this service to match the higher demand

(the most recent issue)


So…servers were scaled…again? I don’t want to sound like a jerk here, but this didn’t work five months ago, and I’m skeptical it’ll work now.

I can appreciate this statement:

We continue to make improvements to this service to provide a consistent experience to our users.

…but I don’t believe that this issue is, in fact, “resolved.”


What I Wanted to Do

Run npm audit.
Expected to get the npm audit security report for my project.

What Happened Instead

Got this error:

> preact-demo@1.0.0 test:audit /home/emilis/...some-path.../preact-demo
> npm audit
npm ERR! code ENOAUDIT
npm ERR! audit Your configured registry (https://registry.npmjs.org/) does not support audit requests.
npm ERR! A complete log of this run can be found in:
npm ERR!     /home/emilis/.npm/_logs/2019-01-15T11_06_44_261Z-debug.log
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! preact-demo@1.0.0 test:audit: `npm audit`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the preact-demo@1.0.0 test:audit script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR!     /home/emilis/.npm/_logs/2019-01-15T11_06_44_287Z-debug.log
npm ERR! Test failed.  See above for more details.

Related debug.log:

0 info it worked if it ends with ok
1 verbose cli [ '/home/emilis/Downloads/node-v11.2.0-linux-x64/bin/node',
1 verbose cli   '/home/emilis/bin/npm',
1 verbose cli   'run',
1 verbose cli   'test:audit' ]
2 info using npm@6.4.1
3 info using node@v11.2.0
4 verbose run-script [ 'pretest:audit', 'test:audit', 'posttest:audit' ]
5 info lifecycle preact-demo@1.0.0~pretest:audit: preact-demo@1.0.0
6 info lifecycle preact-demo@1.0.0~test:audit: preact-demo@1.0.0
7 verbose lifecycle preact-demo@1.0.0~test:audit: unsafe-perm in lifecycle true
8 verbose lifecycle preact-demo@1.0.0~test:audit: PATH: /home/emilis/Downloads/node-v11.2.0-linux-x64/lib/node_modules/npm/node_modules/npm-lifecycle/node-gyp-bin:/home/emilis/work/augmented-writter/preact-demo/node_modules/.bin:/home/emilis/Downloads/node-v11.2.0-linux-x64/lib/node_modules/npm/node_modules/npm-lifecycle/node-gyp-bin:/home/emilis/work/augmented-writter/preact-demo/node_modules/.bin:/home/emilis/.npm-packages/bin:/home/emilis/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
9 verbose lifecycle preact-demo@1.0.0~test:audit: CWD: /home/emilis/work/augmented-writter/preact-demo
10 silly lifecycle preact-demo@1.0.0~test:audit: Args: [ '-c', 'npm audit' ]
11 silly lifecycle preact-demo@1.0.0~test:audit: Returned: code: 1  signal: null
12 info lifecycle preact-demo@1.0.0~test:audit: Failed to exec test:audit script
13 verbose stack Error: preact-demo@1.0.0 test:audit: `npm audit`
13 verbose stack Exit status 1
13 verbose stack     at EventEmitter.<anonymous> (/home/emilis/Downloads/node-v11.2.0-linux-x64/lib/node_modules/npm/node_modules/npm-lifecycle/index.js:301:16)
13 verbose stack     at EventEmitter.emit (events.js:182:13)
13 verbose stack     at ChildProcess.<anonymous> (/home/emilis/Downloads/node-v11.2.0-linux-x64/lib/node_modules/npm/node_modules/npm-lifecycle/lib/spawn.js:55:14)
13 verbose stack     at ChildProcess.emit (events.js:182:13)
13 verbose stack     at maybeClose (internal/child_process.js:978:16)
13 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:265:5)
14 verbose pkgid preact-demo@1.0.0
15 verbose cwd /home/emilis/work/...some-path.../preact-demo
16 verbose Linux 4.15.0-43-generic
17 verbose argv "/home/emilis/Downloads/node-v11.2.0-linux-x64/bin/node" "/home/emilis/bin/npm" "run" "test:audit"
18 verbose node v11.2.0
19 verbose npm  v6.4.1
20 error code ELIFECYCLE
21 error errno 1
22 error preact-demo@1.0.0 test:audit: `npm audit`
22 error Exit status 1
23 error Failed at the preact-demo@1.0.0 test:audit script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 1, true ]

Reproduction Steps

Run npm audit in a project.

Details

The issue happens sometimes when I run npm audit via another npm script.

In this instance npm test.

Excerpt from package.json:

    "test": "npm run test:eslint && npm run test:sasslint && npm run test:jest && npm run test:audit",
    "test:audit": "npm audit",

Platform Info

$ npm --versions
{ 'preact-demo': '1.0.0',
  npm: '6.4.1',
  ares: '1.15.0',
  cldr: '34.0',
  http_parser: '2.8.0',
  icu: '63.1',
  modules: '67',
  napi: '3',
  nghttp2: '1.34.0',
  node: '11.2.0',
  openssl: '1.1.0i',
  tz: '2018e',
  unicode: '11.0',
  uv: '1.23.2',
  v8: '7.0.276.38-node.11',
  zlib: '1.2.11' }

$ node -p process.platform
linux


Unable to do any audits at all now. This is completely blocking our entire project. We’ve now had about 50 ENOAUDITs in a row now.


No errors on my end for the last couple of hours.

Will see how it works tomorrow.


Geographicly the error happened both on my machine in Vilnius, Lithuania (via same ISP, but different locations) and on our GitLab CI servers (which is somewhere in the clouds).


I cannot reproduce the error anymore. I ran npm audit ~30 times, our npm test script 10 times in a row and ran the test suite in the CI. They all finished without errors.

Not sure what you did, but it seems fixed for now :slight_smile:


Sorry about that, we are working on it, but the problem should have been diminished a lot since yesterday. I’ll get back to you as soon as I have more information on the status of this.


It’s the same for me as well, builds are failing intermittently, I had to bypass it but not concerned about vulnerability.


I’m seeing this issue now too. Is it an issue with Node 10 or something?

➜  guidemaker-ember-template git:(master) npm -v
6.9.0
➜  guidemaker-ember-template git:(master) node -v
v10.12.0

Also is there a workaround to get this working properly?


We are actually making infrastructure changes be sure it won’t happen again. ETA should be about 2 hours. I’ll update this thread, but in the meantime, you can also follow on the status page.


Hello,

Experiencing this issue also with our CI pipeline, through CircleCI.
I get this same error time to time, it disappear after some hours; then come back later and so on.
I’m in the same case as @rthewhite, we’re getting too much false-positives and we don’t have any feedback on what’s going on because it’s on npm side.

Node 10.9.0
npm: 6.2.0


Thanks for the feedback @emilis-tm!


Just want to confirm that I haven’t seen a single error in the last 24h. I have run my script a few times both yesterday and today.


Have been seeing this intermittently as well. This makes build fails.
Is there an ETA for this fix? Is there a plan to add retry on npm client side as well?


I can reproduce it also. Seems like a server issue. I’ll talk to the team, sorry about that.


This 503 error is happening constantly for npm audit coming out of OWASP Dependency Checker. Will the service be improved again so that we can get a complete run?


The successful npm audit calls take ~2-4 seconds.
The ENOAUDIT take ~14-15 seconds.

I am using this shell script to test: for (( i=0; $i < 20; i= $i + 1 )) do echo $i; date; npm audit; date; sleep 1; done

The output looks like this:

0
Tr saus. 16 12:19:30 EET 2019
                                                                                
                       === npm audit security report ===                        
                                                                                
found 0 vulnerabilities
 in 27550 scanned packages
Tr saus. 16 12:19:32 EET 2019
1
Tr saus. 16 12:19:33 EET 2019
                                                                                
                       === npm audit security report ===                        
                                                                                
found 0 vulnerabilities
 in 27550 scanned packages
Tr saus. 16 12:19:35 EET 2019
2
Tr saus. 16 12:19:36 EET 2019
npm ERR! code ENOAUDIT
npm ERR! audit Your configured registry (https://registry.npmjs.org/) does not support audit requests.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/emilis/.npm/_logs/2019-01-16T10_19_50_560Z-debug.log
Tr saus. 16 12:19:50 EET 2019
3
Tr saus. 16 12:19:51 EET 2019
                                                                                
                       === npm audit security report ===                        
                                                                                
found 0 vulnerabilities
 in 27550 scanned packages
Tr saus. 16 12:19:54 EET 2019

...


@kmrachko I guess you can try yarn, however it uses same npm registry


This is also a constant issue for us in our Jenkins builds. Would be great if we could get an update on if a fix is planned?


We have the same issue. We use npm audit in our build pipeline and it often fails. (1 out of 3).

npm ERR! code ENOAUDIT
npm ERR! audit Your configured registry (https://registry.npmjs.org/) does not support audit requests.

npm ERR! A complete log of this run can be found in:

I extended audit.js a bit and could extract the following error response from npm:

{ Error: 503 No backends available - POST https://registry.npmjs.org/-/npm/v1/security/audits
    at res.buffer.catch.then.body (/usr/local/lib/node_modules/npm/node_modules/npm-registry-fetch/check-response.js:94:15)
    at process.internalTickCallback (internal/process/next_tick.js:77:7)
  headers:
   [Object: null prototype] {
     date: [ 'Wed, 16 Jan 2019 10:00:17 GMT' ],
     'content-type': [ 'application/json' ],
     'content-length': [ '42' ],
     connection: [ 'keep-alive' ],
     'set-cookie':
      [ '__cfduid=*******; expires=Thu, 16-Jan-20 10:00:04 GMT; path=/; domain=.registry.npmjs.org; HttpOnly' ],
     'expect-ct':
      [ 'max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"' ],
     vary: [ 'Accept-Encoding' ],
     server: [ 'cloudflare' ],
     'cf-ray': [ '499fbba17f78bd98-AMS' ],
     'x-fetch-attempts': [ '1' ] },
  statusCode: 503,
  code: 'E503',
  method: 'POST',
  uri: 'https://registry.npmjs.org/-/npm/v1/security/audits',
  body: { message: 'No frontdoor hosts available' },
  message:
   '503 No backends available - POST https://registry.npmjs.org/-/npm/v1/security/audits' }


Any updates on this? Found this conversation addressing this at the CLI level, but it’d be nice to know whether or not the server-side issue is being worked on.

We recently added npm audits to our CI/CD pipeline, and we’re hitting this issue infrequently leading to a non-trivial amount of false-negatives in our pipeline.

We can probably anticipate this behavior of the audit endpoint and automate a retry, but that seems like an unsustainable band-aid.


My (temporary?) solution:

      for n in {1..5}; do
        audit=`npm --color always audit 2>&1`
        echo "$audit"
        if [[ "$audit" != *"ENOAUDIT"* ]]; then
          break
        fi
      done


It should be better now, but we are still working on a fix.


Started getting this error today running npm audit. So it’s clearly not fixed yet.

HttpErrorGeneral: 503 No backends available - POST https://registry.npmjs.org/-/npm/v1/security/audits
    at res.buffer.catch.then.body (/usr/local/lib/node_modules/npm/node_modules/npm-registry-fetch/check-response.js:104:15)
    at process._tickCallback (internal/process/next_tick.js:68:7)


For a long time it was working fine. Now we are experiencing this issue constantly.


Sorry all, I cannot help anymore. I hope they’ll fix it.

I know @iarna was supposed to surface this in the product meeting.

Fred


Can confirm we run into this issue regularly as well in our CI pipelines. Had the same pipeline running this morning all fine, in the afternoon it failed with the exact same error as above.

We are running these in the cloud on Azure DevOps, maybe it’s some rate limiting related thing from certain ip ranges?


Still getting this error in packages with big package-lock, removing devDependencies sometimes helps. Pretty sure that problem caused by amount of packages in package-lock. Related issue


FYI, you shouldn’t get anymore 503 for now, but to ensure it will be completely solved, we are providing more capacity to this service.

Let me know if you have any more problems, but it should be good now.

Thanks for your patience.


Attaching my
package-lock.json (621.9 KB)


Also seeing this intermittently on local dev machines and CI (Concourse CI) with npm@6.9.0. Here are the logs:

0 info it worked if it ends with ok
1 verbose cli [ '/usr/local/Cellar/node/11.11.0/bin/node',
1 verbose cli   '/usr/local/bin/npm',
1 verbose cli   'audit' ]
2 info using npm@6.9.0
3 info using node@v11.11.0
4 verbose npm-session e2849a2da393f6d3
5 http fetch POST 502 https://registry.npmjs.org/-/npm/v1/security/audits 9589ms
6 verbose stack Error: Your configured registry (https://registry.npmjs.org/) does not support audit requests, or the audit endpoint is temporarily unavailable.
6 verbose stack     at Bluebird.all.spread.then.catch (/usr/local/Cellar/node/11.11.0/lib/node_modules/npm/lib/audit.js:201:18)
6 verbose stack     at tryCatcher (/usr/local/Cellar/node/11.11.0/lib/node_modules/npm/node_modules/bluebird/js/release/util.js:16:23)
6 verbose stack     at Promise._settlePromiseFromHandler (/usr/local/Cellar/node/11.11.0/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:512:31)
6 verbose stack     at Promise._settlePromise (/usr/local/Cellar/node/11.11.0/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:569:18)
6 verbose stack     at Promise._settlePromise0 (/usr/local/Cellar/node/11.11.0/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:614:10)
6 verbose stack     at Promise._settlePromises (/usr/local/Cellar/node/11.11.0/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:690:18)
6 verbose stack     at _drainQueueStep (/usr/local/Cellar/node/11.11.0/lib/node_modules/npm/node_modules/bluebird/js/release/async.js:138:12)
6 verbose stack     at _drainQueue (/usr/local/Cellar/node/11.11.0/lib/node_modules/npm/node_modules/bluebird/js/release/async.js:131:9)
6 verbose stack     at Async._drainQueues (/usr/local/Cellar/node/11.11.0/lib/node_modules/npm/node_modules/bluebird/js/release/async.js:147:5)
6 verbose stack     at Immediate.Async.drainQueues [as _onImmediate] (/usr/local/Cellar/node/11.11.0/lib/node_modules/npm/node_modules/bluebird/js/release/async.js:17:14)
6 verbose stack     at processImmediate (timers.js:637:19)
7 verbose cwd /Users/sally/workspace/teachers
8 verbose Darwin 18.0.0
9 verbose argv "/usr/local/Cellar/node/11.11.0/bin/node" "/usr/local/bin/npm" "audit"
10 verbose node v11.11.0
11 verbose npm  v6.9.0
12 error code ENOAUDIT
13 error audit Your configured registry (https://registry.npmjs.org/) does not support audit requests, or the audit endpoint is temporarily unavailable.
14 verbose exit [ 1, true ]


Seeing a lot of this today as well. As a stop-gap it would be useful if ENOAUDIT and actual audit failures exited with different exit codes (currently both exit with 1) so at the absolute worst we could write wrappers to distinguish between actual failures and flaky infrastructure.


For running npm audit as part of a CI/CD pipeline, this issue is quite bad, as it makes our pipeline often fail for no good reason. Is there any way to cache the audits database with a third party registry, such as nexus open source? I can’t find any docs on this.

Any idea when this will be resolved?


@yoazmenda It’s been reported inside npm and is on the product team’s board, but I’m also no longer in a position to to do more than that.


This is still happening to us, albeit far less frequently. We’ve seen a couple of one-off instances since this change went in back in January, however today we’ve seen a sharp increase.

Is this still an issue server side? Or is it an expected error that the CLI needs updated to more accurately convey?


Same. Has been bad the last few weeks but today it has become so bad I’ve just had 10 fail in a row and I’m going to be forced to bypass this which puts my project at risk


Have been seeing this intermittently but yesterday and today it has been awful. We had seven builds fail in a row due to this issue, and this morning I can’t get anything to build.


@fharper sorry to hear that.

@iarna any updates on this you can provide? This continues to not only occur, but is seemingly increasing in frequency. Is this on the product team’s radar?


you might want to disable audit on CI (--no-audit or npm config set audit false or set audit=false in your CI’s .npmrc file)


Succeeded in getting this error directly via npm audit:

preact-demo$ npm audit
npm ERR! code ENOAUDIT
npm ERR! audit Your configured registry (https://registry.npmjs.org/) does not support audit requests.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/emilis/.npm/_logs/2019-01-15T15_36_29_473Z-debug.log

debug.log:

$ cat /home/emilis/.npm/_logs/2019-01-15T15_36_29_473Z-debug.log
0 info it worked if it ends with ok
1 verbose cli [ '/home/emilis/Downloads/node-v11.2.0-linux-x64/bin/node',
1 verbose cli   '/home/emilis/bin/npm',
1 verbose cli   'audit' ]
2 info using npm@6.4.1
3 info using node@v11.2.0
4 verbose npm-session 1c5b33e83ba090b7
5 timing audit compress Completed in 17ms
6 info audit Submitting payload of 107466 bytes
7 http fetch POST 503 https://registry.npmjs.org/-/npm/v1/security/audits 13097ms
8 verbose stack Error: Your configured registry (https://registry.npmjs.org/) does not support audit requests.
8 verbose stack     at Bluebird.all.spread.then.catch (/home/emilis/Downloads/node-v11.2.0-linux-x64/lib/node_modules/npm/lib/audit.js:172:18)
8 verbose stack     at tryCatcher (/home/emilis/Downloads/node-v11.2.0-linux-x64/lib/node_modules/npm/node_modules/bluebird/js/release/util.js:16:23)
8 verbose stack     at Promise._settlePromiseFromHandler (/home/emilis/Downloads/node-v11.2.0-linux-x64/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:512:31)
8 verbose stack     at Promise._settlePromise (/home/emilis/Downloads/node-v11.2.0-linux-x64/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:569:18)
8 verbose stack     at Promise._settlePromise0 (/home/emilis/Downloads/node-v11.2.0-linux-x64/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:614:10)
8 verbose stack     at Promise._settlePromises (/home/emilis/Downloads/node-v11.2.0-linux-x64/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:689:18)
8 verbose stack     at Async._drainQueue (/home/emilis/Downloads/node-v11.2.0-linux-x64/lib/node_modules/npm/node_modules/bluebird/js/release/async.js:133:16)
8 verbose stack     at Async._drainQueues (/home/emilis/Downloads/node-v11.2.0-linux-x64/lib/node_modules/npm/node_modules/bluebird/js/release/async.js:143:10)
8 verbose stack     at Immediate.Async.drainQueues [as _onImmediate] (/home/emilis/Downloads/node-v11.2.0-linux-x64/lib/node_modules/npm/node_modules/bluebird/js/release/async.js:17:14)
8 verbose stack     at processImmediate (timers.js:632:19)
9 verbose cwd /home/emilis/...some-path.../preact-demo
10 verbose Linux 4.15.0-43-generic
11 verbose argv "/home/emilis/Downloads/node-v11.2.0-linux-x64/bin/node" "/home/emilis/bin/npm" "audit"
12 verbose node v11.2.0
13 verbose npm  v6.4.1
14 error code ENOAUDIT
15 error audit Your configured registry (https://registry.npmjs.org/) does not support audit requests.
16 verbose exit [ 1, true ]


Just a quick heads up: we saw this occur again just 15 minutes ago. Not sure if that’s a side-affect of the in-flight infrastructure changes or not.


It’s much better now but issue still occurs from time to time.


Getting this all the time, it just stopped working few weeks ago and since then not even once it returned success… Not sure if that feature is useful in this kind of state. Is it possible to use some 3rd party with similar functionality, but more capable servers?


Well i have that CI pipeline running daily for it’s sole purpose of checking whether any new vulnerabilities have been found since last check. So disabling it is not what i’m looking for, i want to run it reliable without false positives.

Basically i’m in the same boat as JordanForeman, it’s hard to convince people that npm audit is a valuable tool since currently the amount of false positivies (CI failing because of the described error) is to high.

But we, as a team and company, believe that it’s part of secure software development to keep track of any vulnerabilities and mitigate if needed.


At a risk of repeating others, this is occurring at random within my build pipeline. I build and audit ~20 projects at a time, and 4-5 of them will fail, but different ones each time. We want to leave this auditing on for security reasons, but it needs to be reliable.
Thank you @travi for the link to the incident - will be following closely.


@emilis-tm: let me know how it goes please.


@JordanForeman: our support team is mostly available from 6AM - 6PM Pacific Time so someone will get back to you soon.


(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)


This is still happening in our CI environment. The volume of false negatives this has introduced has degraded confidence in our CI pipeline and is making it difficult for me to convince my team that npm audit is a valuable tool for us to continue using.

14:59:35         throw err;
14:59:35         ^
14:59:35 npm ERR! code ENOAUDIT
14:59:35 npm ERR! audit Your configured registry (https://registry.npmjs.org/) does not support audit requests.

Our CI environment is using npm@6.4.1, so we don’t have the latest audit CLI; meaning that isn’t necessarily a 404 like you’d expect looking at the latest CLI source code. Let me know if there’s any more information I can provide to help get this resolved. This seems like a very promising tool and I’d like to see it reach its full potential despite these issues.

edit: also, status.npmjs.org suggests no issues at the current time


Our team is looking at it right now, thanks for letting us know @emilis-tm


We had an incident yesterday, but it should be fixed now.


I’m sorry about that! I’m verifying with our team and will get back to you.