3 ms·
> 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 a
by thedaniel 10y ago
> 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 I don't think I'd start assigning blame to the Code team.
- mjpa 10y agoSounds like you're describing a mistake there...
- jfindley 10y agoYeah. 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.
- thedaniel 10y agoIndeed: https://whoownsyouravailability.com https://whoownsyouravailability.com
- seldo 10y agoI'm sorry my response looked like I was blaming them, that wasn't my intention. Like I said, it was an honest mistake: these things happen, and they handled it well. Once we determined 404s were the problem we put mitigation in place that worked fine, but the problem of request volume remained: the 10% figure I gave was at a 5% rollout of VSCode. A full rollout would therefore have meant the registry became 3x bigger overnight and two thirds of that would have been 404s to VSCode users. At that point the issue is financial, not technical, which is another reason the rollback happened.
- joepie91_ 10y agoHmm. What is the "mitigation"?
- seldo 10y agoMore efficiently handling 404s, which as many have pointed out we were handling quite naïvely.
- joepie91_ 10y agoRight, but I'm curious what exactly the issue was (on a technical level), and how you've mitigated it. This might be useful knowledge for other people building similar things, to avoid making the same mistakes :)
- seldo 10y agoCheck out my detailed answer a few comments down: https://news.ycombinator.com/item?id=12861180 https://news.ycombinator.com/item?id=12861180
- i336_ 10y agoHi, I just wanted to say kudos for this little reply thread. Many times I've seen someone on HN write a negative/flaming reply to a comment, which then nets a bunch of further agreement and consensus, and the original commentator is nowhere to be seen. You quickly responded and fully acknowledged the faux pas (nuking any negative consensus), then you replied twice more, and one of those replies was to a request for technical info. /o/
- lucideer 10y agoOn the contrary, this seems like too kind a stance for npm to take. The approach Microsoft took here seems enormously and unnecessarily inefficient. Microsoft maintain the @types scope. Instead of providing their own metadata endpoint listing available typings to filter requests on, they lazily opted to just mass bombard a repository they maintain, hosted on a free service they don't fund, for any and all possible package names, even though they themselves maintain the list of packages and should know in advance which don't exist.