Keep getting status code 500 when using scoped npm packages

[svi3c]

Hi,

I tried to install some new dependencies today.
When I try to run jspm install, I get errors like this:

err  Error on lookup for npm:@angular/core
Invalid status code 500

err  Error on lookup for npm:@angular/platform-browser-dynamic
Invalid status code 500

err  Error on lookup for npm:@ngrx/store
Invalid status code 500

err  Error looking up npm:@angular/core.

or this:

err  Error: socket hang up
    at createHangUpError (_http_client.js:250:15)
    at TLSSocket.socketOnEnd (_http_client.js:342:23)
    at emitNone (events.js:91:20)
    at TLSSocket.emit (events.js:185:7)
    at endReadableNT (_stream_readable.js:926:12)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    at process._tickCallback (internal/process/next_tick.js:98:9)

err  Error on lookup for npm:@angular/compiler
Invalid status code 500

err  Error on lookup for npm:@angular/core
Invalid status code 500

err  Error on lookup for npm:@angular/platform-browser
Invalid status code 500

err  Error on lookup for npm:@ngrx/core
Invalid status code 500

err  Error looking up npm:@angular/compiler.

The number of erroring requests seems to vary and when I try to install one of those package at a time, it seems to work sometimes and sometimes it does not (tested with npm:@angular/core).

I tried update my JSPM (from v0.17.0.beta.14 to v0.17.0-beta.21), but got the same problem.
A colleague had the same problem when I asked him to reproduce the issue.
It works without problems when installing the problematic packages via npm.

I reproduced the behaviour in this project:
https://github.com/flaviait/ng2-jspm-template

Any ideas what could be causing this issue?

[bmayen]

We're seeing the same thing. Not seeing any issue installing directly via npm, but jspm i requires a few retries before it succeeds.

[UXabre]

Indeed, noticed the same here and tried about everything in my power:

• Authenticating
• Clearing caches (one becomes paranoia)
• Extending timeouts (although the chances for this work were dismal as jspm is normally able to detect this...)

Is there a possibility that angular2 is hosting their own npm service and that this seems to fail for whatever reason?

I have also created an SO question on the topic (which actually guided me here):
http://stackoverflow.com/questions/37790812/server-sometimes-returns-500-when-installing-angular

Maybe here I can cast my vote for a verbose mode, in which we can learn if besides the 500 code, we can actually see some output that the server might have send additionally (e.g. server flooded, google out-of-money, ... ) ?

[jakeNiemiec]

+1 Same error. Nothing changed in my project over the weekend. I even tried with the latest 0.17 branch (21). Related: jspm/npm#136

[madhukard]

+1 same error in my angular 2 project as well.

[jakeNiemiec]

It may be a change with npm. I am also using angular.

[musabhusaini]

+1

[lutzj82]

+1

[jakeNiemiec]

This, right here, is why people check node_modules/ into source control.

Here is a script that concurrently requests a tar like npm 100 times:

$ seq 100 | parallel -j0 --joblog log curl -s -I --write-out %{http_code} https://registry.npmjs.org/@angular/router/-/router-2.0.0-rc.1.tgz">" {}.txt && tail -n 2 -q *.txt | sort | uniq -c | sort -r
Output:

Academic tradition requires you to cite works you base your article on.
When using programs that use GNU Parallel to process data for publication
please cite:

  O. Tange (2011): GNU Parallel - The Command-Line Power Tool,
  ;login: The USENIX Magazine, February 2011:42-47.

This helps funding further development; AND IT WON'T COST YOU A CENT.
If you pay 10000 EUR you should feel free to use GNU Parallel without citing.

To silence the citation notice: run 'parallel --citation'.

// Status Codes:
  72 401 
  27 200
   1 401
   1

It seems like it will limit you to 25 requests per minute. However, the jspm-cli error gives a 500 error that I could not reproduce.

[OrKoN]

var request = require('request');

request({ uri: 'https://registry.npmjs.org/@angular%2Fcommon',
  gzip: true,
  strictSSL: true,
  headers: 
   { 'if-none-match': '"1SGC6WAH14BSNAYHU5RBQV3S5"',
     authorization: 'Bearer fa733155-1ffe-4b2e-8661-ea4b10aa3e18' } },
function(err, response) {
      console.log(err, response.statusCode);
     })

this seems to reproduce the error. Outputs:

null 500 '{"error":"Authorization service failure"}'

sometimes returns 304. Looks like NPM problem. Can someone report?

[jakeNiemiec]

See: https://gitter.im/jspm/jspm?at=575f22466092456f6633da6c

1000 curl requests to https://registry.npmjs.org/angular returns:

• 1000 http_status: 200

1000 curl requests to https://registry.npmjs.org/@angular%2Fupgrade returns:

• 730 http_status: 401
• 248 http_status: 500
• 22 http_status: 200
• Total = 1000

This is reasonable proof that this is an npm hosting problem.

[jakeNiemiec]

Everything seems to work more often if you are logged in to npm login. I can now run jspm install. @guybedford perhaps we may need some cli messages warning users about rate limiting on users who are not logged in. Credit also goes to @mainnika

[UXabre]

Seems like the problem resolved itself now? At least in my case I can use jspm install again as expected :-)

[screendriver]

Everything seems to work more often if you are logged in to npm login

I am always logged in to npm and had the issue yesterday as well. But now it seems to work at the moment.

I'm curious about the cause of this issue. Our whole continuous integration system went down yesterday because of this.

[jakeNiemiec]

@screendriver Same here. I removed the ~/.npmrc file and re-logged. It started working better after that.

[screendriver]

@guybedford do you know what caused this issue? I have to report it to my boss in my company.

[guybedford]

@screendriver it was npm making changes to their API, and breaking an API that the npm CLI tool does not itself directly rely on but that we do.

[jakeNiemiec]

@guybedford @screendriver I am in contact with npm support on this. I'll update here if I find anything out.

[jakeNiemiec]

Update (for any googlers) from @soldair:

we had an issue with one authentication server around this time. It failed in a new way we did not have alert coverage for.

I can confirm that it is working without being logged in to npm. (//cc @mainnika)