Earlier quoted context omitted.
Embed both in the page.
I suspect most folks, especially ones which operate at GB/s rates serving traffic would not like to serve up a 100kb base64 encoded image every time an error is thrown.
What the Fastly outage can teach us about writing error messages
71–80 of 137 posts
Re: What the Fastly outage can teach us about writing error messages
#72Isn't it time we had more error messages? I feel like we got 40x, 50x and the pioneers left lots of space for more. I quite liked the windows 0x800*** hex error numbers, though some were more useful than others.
New error codes are only useful if they are generally understood. Maybe instead of using more codes for sub-use-cases, use the permissible error text to express these (HTTP-Status: 503 0x63F0 Data corrupt ?)
Re: What the Fastly outage can teach us about writing error messages
#73Because when you develop things you are the end consumer.
Re: What the Fastly outage can teach us about writing error messages
#74For example: Cannot serve website. (What?) Reason: could not connect to database. (Why?)
Most of the time, it is very easy to programmatically assemble such messages. It is much harder to automatically figure out who caused it and when it will be fixed.
Re: What the Fastly outage can teach us about writing error messages
#75Earlier quoted context omitted.
Good error messages have a template: a UUID, a description, and a suggested solution. This gives folks enough to try to solve it themselves and also enough to Google / grep with.
You can’t suggest a solution because if you were aware of the problem enough to suggest a solution you would just fix the problem. This 503 error from fastly was never meant to show to a user. You can’t do much to account for novel situations which shouldn’t ever happen.
Re: What the Fastly outage can teach us about writing error messages
#76Unfortunately the majority of internet users aren't trained in the art of reading HTTP status codes I think the majority know what 404 is, and possibly 403, but I agree about the more obscure ones. That said, I don't think it's a bad idea to rely on the "default exception handling behaviour" that the majority of users, even non-computer-literate ones, will have: they'll retry a few times, see that it doesn't work, an…
No more www, no more protocol in the address bar and apple is selling iMac colors in it's commercials...
Re: What the Fastly outage can teach us about writing error messages
#77Reminds me of the quintessential tweet about error messages https://twitter.com/cherrikissu/status/972524442600558594?s=...
Right up there with Slack etcs fake loading messages "Gearing up the dildonator" "Implicating the fairies" "Hogtying George Bush" Dude - just give me a spinner or a progress bar, and if something errors during the load out give me some sort of stack trace or error ID I can use to help
Re: What the Fastly outage can teach us about writing error messages
#78I'm a believer in not hiding things and logging the whole problem all the way to the end consumer: http://test.rupy.se/?id=2 Because when you develop things you are the end consumer.
Technical errors are way better than just "I'm sorry we couldn't process that right now."
Re: What the Fastly outage can teach us about writing error messages
#79Have they published a post-mortem for the outage yet? I'm curious as to what happened here
Here it is https://www.fastly.com/blog/summary-of-june-8-outage Posted about 17 hours after the incident. In short, a valid customer configuration change triggered a bug. One thing I don't see in this writeup is a commitment to ensure that customer configurations cannot break the whole system. Cloudflare does seem to make this promise with their zero trust architecture, https://www.cloudflare.com/learning/security/gl…
Fastly's downtime seems to be caused by an automatically generated config that got deployed in production as a result of change requested by a legitimate customer.
This happened to CF in its early days and I really doubt that ZT had anything to do with the fact that they do not have this kind of problem anymore. It's probably some sanity checks before they deploy updated lua scripts to their fleet of nginx's if anything.
Re: What the Fastly outage can teach us about writing error messages
#80Have they published a post-mortem for the outage yet? I'm curious as to what happened here
Here it is https://www.fastly.com/blog/summary-of-june-8-outage Posted about 17 hours after the incident. In short, a valid customer configuration change triggered a bug. One thing I don't see in this writeup is a commitment to ensure that customer configurations cannot break the whole system. Cloudflare does seem to make this promise with their zero trust architecture, https://www.cloudflare.com/learning/security/gl…
The generic topic your looking for is probably something like "customer isolation" ("service isolation" might also be relevant, but is used also in the context of "tenant isolation" which isn't really what you want). See this thread: https://news.ycombinator.com/item?id=25237836 for some talk about how AWS does "cellularization" which is a form of workload/service isolation/partitioning.
In general I don't think there's much discussion of this issue on the wider web.