1486214 - investigate sentry-style crash report format and API

Status: RESOLVED FIXED

(Socorro :: General, task, P2)

Description

[Will Kahn-Greene [:willkg] ET needinfo? me]

This bug covers looking into how the Sentry libraries send crash reports to a Sentry server.

What format is it in? What does the HTTP request look like? What keys are present? How does it compare to breakpad-style crash reports that Firefox/Fennec send?

Comment 1

[Will Kahn-Greene [:willkg] ET needinfo? me]

Grabbing this to work on this week.

Comment 2

[Will Kahn-Greene [:willkg] ET needinfo? me]

Sentry clients are here:

   https://docs.sentry.io/clients/

Documentation for writing a client is here:

   https://docs.sentry.io/clientdev/

That says that clients are sending HTTP POST payloads in JSON format with this data ("attributes" and "interfaces"):

   https://docs.sentry.io/clientdev/attributes/
   https://docs.sentry.io/clientdev/interfaces/

Mike pointed out that different Sentry clients send different information. For example, the Exception structure can vary between clients. We might need to do sdk-specific normalization of data we're using.

So... this would involve something like:

1. Adding a new handler in Antenna for Sentry-style payloads. It's built for multiple handlers, so this isn't a big deal unless all reporting has to use the same /submit endpoint. If that's the case, then we'd need to adjust that endpoint to route the different crash report types to their respective handlers. I think that's pretty easy to do.

2. Adjust the processor so that it has a rule to pull out all the breakpad-specific data from the raw crash into the processed crash. This work is currently spread out across a bunch of rules.

3. Add a new rule to the processor to pull out all the sentry-specific data from the raw crash into the processed crash.

4. Write up some rules about sending Sentry-style crash reports. Namely we'd probably want the "release" attribute to be the build id. Things like that. 


I think that's about it.

To conclude, it's definitely doable and I don't think it's a big project. I think there was some thought about this already in Socorro history and it's likely I removed some of the work that was done at the time in one of my "delete the stuff we're not using" passes.

Marking as FIXED.