3 ms·
It's the not handling an API failure correctly that surprises me. That seems like it'd be quite common
by astonex 8y ago
It's the not handling an API failure correctly that surprises me. That seems like it'd be quite common
- cwyers 8y agoI mean, sometimes handling an API failure correctly is failing over. If an API call actually matters, then when the API stops responding, throw an error. Even if you're probably catching that and giving out an error message, I'd still call that a production outage.
- astonex 8y agoWe have a differing opinions on what outage means then. Catching the error and showing it to the user is obviously the right thing to do, but not what I'd call an outage.
- drchickensalad 8y agoI can't say I've ever met a developer who thinks that a 100% error rate to valid requests isn't an outage. Not sure why you have such a strong view of your semantics.
- function_seven 8y agoSure it is, if it affects all users at once, and makes your system unusable. If I dial a phone number and get a busy signal, that's an "error" of sorts. If every Verizon user gets that busy tone on every call, that's an outage.
- geofft 8y agoThis is a spam filter, so failing closed seems reasonable. (Failing open is also reasonable too.)
- testplzignore 8y agoThere are lots of potential security issues with npm (compromised accounts, spam packages, etc). I think failing closed is the right thing to do for them. It's a temporary annoyance and loss of productivity for a day - a good time to put your feet up and relax. Failing open could lead to a costly security breach that affects many people, and could lead to npm's demise.