ENOAUDIT from registry.npmjs.org (503)

triaged
registry
priority:critical
(Frédéric Harper) #21

Thanks for the feedback @emilis-tm!

(Emilis Dambauskas (Tokenmill)) #22

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.

2 Likes
(Brandon Hedge) #23

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

1 Like
(Jordan Foreman) #24

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?

(Frédéric Harper) #25

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

2 Likes
(Jordan Foreman) #26

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

(Oliver Peate) #27

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 ]
(Frédéric Harper) #28

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

(Raymond De Wit) #29

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?

1 Like
(Luis Lobo Borobia) #30

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)

(Raymond De Wit) #31

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.

2 Likes
(William Da Silva) #32

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

(Chris Manson) #33

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?

(Frédéric Harper) #34

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

(Yoaz Menda) #35

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

any updates?

(Jordan Foreman) #36

@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?

(Rebecca Turner) #37

@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.

1 Like
(Justin Grant) #39

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)
(Deven Phillips) #40

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!

1 Like
(Jordan Foreman) #41

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

1 Like