Evaluate usefulness of Sentry logs

[amc-corey-cox]

From Vince:
I would verify that 1) you're able to log in and 2) you're able to actually get any debugging value out of the errors it's able to capture

Kevin's thoughts:
Having just some aggregated stats about the errors might even be good.

I also said this:
I didn't even know we have it... on the other hand. Seeing what errors we're getting does have some merit. We have another issue we're working on this month with respect to logs. Should we consider this with it?

So let's take a look and see if we think Sentry is useful. If not, we might as well pull it out.

This is tangentially related to #604.

[vincerubinetti]

My notes/thoughts:

• First and foremost, make sure someone can -- and will -- log in and do something with the results. Otherwise it's just added maintenance burden. Personally I have not looked at the logs since I hooked up the service some years ago.
• Check if the logs it produces can actually help you debug. In the production build of the app, code will be minified, and I'm unsure whether Sentry will have access to the source maps (you'll have to set this vite option to true) and be able to reconstruct original file names, line numbers, variable names, etc.
• Sentry does have this cool distributed tracing feature where you can trace an error from "end to end". E.g., you'd hook up the Sentry Python SDX to the backend, then frontend makes a request, the backend processes it, and Sentry is able to connect the dots and see that as a single event (I guess by sending some unique identifier along with every request).

Regarding source maps, it's possible all the error logs could look like "e is undefined", which is not useful even as aggregated statistics. However, I know it at least is able to record the URL (dev vs. beta vs. prod), the browser, and I think the location, so those things could be useful, e.g. lots of Safari users are seeing issues.