Live data from Hacker News

Visual Studio Code 1.7 overloaded npmjs.org, release reverted

code.visualstudio.com

61–70 of 94 posts

Re: Visual Studio Code 1.7 overloaded npmjs.org, release reverted

#61
post #13

I'd just like to say on behalf of npm that Microsoft's handling of this incident was A+. As soon as we alerted them to the issue they were all hands on deck and did a rollback. We've been really pleased that Microsoft chose to put their @types packages into the npm registry rather than a separate, closed system, and in general happy with Microsoft's support of node and npm. We're confident we can make the new feature…

> This was an honest mistake on their part From my outside perspective, it doesn't seem like a mistake on their part at all. Later in the thread you say this accounted for 10% of traffic, mostly 404s. This is (i assume) a hell of a lot of requests, but given npm's position as developer infrastructure, I don't think they could have reasonably expected to melt it. It would have been good of them to give a heads up, but…

Sounds like you're describing a mistake there...

Re: Visual Studio Code 1.7 overloaded npmjs.org, release reverted

#63
post #13

I'd just like to say on behalf of npm that Microsoft's handling of this incident was A+. As soon as we alerted them to the issue they were all hands on deck and did a rollback. We've been really pleased that Microsoft chose to put their @types packages into the npm registry rather than a separate, closed system, and in general happy with Microsoft's support of node and npm. We're confident we can make the new feature…

> This was an honest mistake on their part From my outside perspective, it doesn't seem like a mistake on their part at all. Later in the thread you say this accounted for 10% of traffic, mostly 404s. This is (i assume) a hell of a lot of requests, but given npm's position as developer infrastructure, I don't think they could have reasonably expected to melt it. It would have been good of them to give a heads up, but…

Yeah. It leaves an unpleasant taste in my mouth to hear npm blaming Microsoft for this. As noted elsewhere, 404's are supposed to be very cheap to handle, otherwise DoS attacks become embarrassingly easy.

I feel like the npm team have once again failed to own their problems and instead tried to push the blame elsewhere. This is just an outside perspective, but I really feel like it would have been more honest and accurate to at least admit to the possibility that npm isn't perfect, and "blame" (which I'm not sure is even a helpful concept in this instance) is shared between parties more equitably.

Re: Visual Studio Code 1.7 overloaded npmjs.org, release reverted

#64

Earlier quoted context omitted.

They do? yarn uses the npm registry not something else.

It does, but it also goes though cloudflare as far as I know (which does caching).

This issue though was with excessive 404s, which aren't cached.

Re: Visual Studio Code 1.7 overloaded npmjs.org, release reverted

#65
post #18

Earlier quoted context omitted.

So one day they switched their entire user base to rely on a 3rd party free service without any load testing or heads up? What could possibly go wrong?

We have been testing this on insider builds of vscode for a few weeks as well as preview builds of visual studio with no issues. We were just notified today by npm that we are flooding their servers.

Before you start sending couple thousand QPS to any server it's generally not a bad idea to test if that server can handle that much, sometimes it is even worthwhile notifying the other team about the intended change.

Overall when you "tested" something, but it still breaks in production and requires a rollback it's usually a sign that your testing strategy isn't could use some improvement - what is the point of testing if it doesn't prevent failures from happening

Re: Visual Studio Code 1.7 overloaded npmjs.org, release reverted

#66
post #22

Earlier quoted context omitted.

Can you elaborate on what the issue is and how you want it to be fixed? Is it just something like rate-limiting requests or something more fundamental? Edit: Answered at https://news.ycombinator.com/item?id=12861118

A VSCode person can (and probably will) answer in more detail, but at heart it's simple: if you want to add type-checking goodness to a library that isn't itself written in TypeScript, you can create a thing called a declaration file: https://github.com/DefinitelyTyped/DefinitelyTyped Microsoft publishes a list of known good declaration files for popular npm packages to npm, under the scope @types: https://www.npmjs.…

> At the moment there are few enough that they could fetch a list of all of them and cache it

at which point they would be back to the annoying race conditions for fresh publishes, no?

Can you speak to why it is so expensive on the NPM side to serve a 404? Would a bloom filter like another commenter mentioned be helpful?

Re: Visual Studio Code 1.7 overloaded npmjs.org, release reverted

#69
post #22

Earlier quoted context omitted.

A VSCode person can (and probably will) answer in more detail, but at heart it's simple: if you want to add type-checking goodness to a library that isn't itself written in TypeScript, you can create a thing called a declaration file: https://github.com/DefinitelyTyped/DefinitelyTyped Microsoft publishes a list of known good declaration files for popular npm packages to npm, under the scope @types: https://www.npmjs.…

"There are any number of ways to fix this, and we'll work with Microsoft to find the best one..." It's refreshing to read actual engineers' writing. After this, going back to tear-jerking snark-filled twitter and medium gnashing of teeth will be hard.

It's better to be part of the solution than to create the problem.

Re: Visual Studio Code 1.7 overloaded npmjs.org, release reverted

#70

Earlier quoted context omitted.

> This was an honest mistake on their part From my outside perspective, it doesn't seem like a mistake on their part at all. Later in the thread you say this accounted for 10% of traffic, mostly 404s. This is (i assume) a hell of a lot of requests, but given npm's position as developer infrastructure, I don't think they could have reasonably expected to melt it. It would have been good of them to give a heads up, but…

Yeah. It leaves an unpleasant taste in my mouth to hear npm blaming Microsoft for this. As noted elsewhere, 404's are supposed to be very cheap to handle, otherwise DoS attacks become embarrassingly easy. I feel like the npm team have once again failed to own their problems and instead tried to push the blame elsewhere. This is just an outside perspective, but I really feel like it would have been more honest and acc…

Indeed: https://whoownsyouravailability.com
Post reply on HN