Comment on Oops, something went wrong!
hperrin@lemmy.ca 1 week agoWhy do you think the vast majority of these messages come from client side issues? I worked as a Site Reliability Engineer at Facebook. We had data on client side errors too. Crash logs are sent to the servers when a client side error happens. There’s not really one source that constitutes a “vast majority” of these error messages, but I can tell you that the plurality of them come from the caching layer.
Cryophilia@lemmy.world 1 week ago
How? I mean how is it possible to send a crash log to the server when the problem is that the client can’t connect to the server?
You by definition don’t see most of these errors except maybe as pings, depending on why it can’t connect
hperrin@lemmy.ca 1 week ago
If it’s a mobile app, the operating system handles crash logs, and reports them to you through your app management portal. Then for connection issues to the host or handled errors, you can store that in your app’s data store.
If it’s a web app, you can save them in local storage through your service worker, then upload them once the connection is restored. If you don’t have a high level error handling function on your web app, that’s an issue with your web app, not your logging infrastructure.
For a network outage error, these aren’t usually reported if the problem is on the client side, since that’s not something we can do anything about. Both mobile apps and service workers can tell if the operating system is disconnected from the network. If it’s an issue connecting to our host (host is unreachable, but network is online), that’s when we’d save the issue and log it later once service is restored.
We can tell when our services go offline, because we have health checks on our hosts. So, technically, we don’t need client side reporting if our hosts are down. But, every place I’ve worked at has had them anyway.