Closed Bug 1323002 Opened 8 years ago Closed 6 years ago

Create and use machine-readable metadata for crash report annotations

Categories

(Toolkit :: Crash Reporting, defect)

Product:
Toolkit
Component:
Crash Reporting
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1348273

People

(Reporter: benjamin, Unassigned)

Details

User Story

USER STORIES:
As data steward, engineer, or analyst, I need a reliable description of every piece of metadata which can be sent with crash reports. (P1)

As data steward, I need the ability to do data review on any changes to crash metadata that is collected.

As engineer and analyst, I need to know the format of each piece of metadata: at a minimum, its data type (int, decimal, hex, float, JSON, etc) (P2)

As data steward, engineer, or analyst, I want to know which pieces of metadata are sent with opt-in submitted crashes and which are sent with opt-out crash pings. (P1)

As an engineer, I want to restrict certain metadata to be reported only with some types of crashes. (P2)

As an engineer, when I add a new piece of metadata I want it to show up ASAP in supersearch and the parquet dataset with the correct data type and privacy restrictions without having to ask the socorro team to add it explicitly. (P2)

As data steward, I want to make it possible to "expire" certain metadata after a certain release, just as telemetry histograms can expire (P2).

SUCCESS CRITERIA:

We will know we have succeeded when teams collecting data stop using freetext "notes" fields and instead use structured fields.

PROPOSED TECHNICAL SOLUTION:

In the source tree use a manifest (YAML/JSON) like we have for histograms and scalars. Each piece of metadata is described in this manifest including datatype, opt-in/out status, expiration, etc. This manifest is used to enforce that we annotate only "known" crash metadata and as the whitelist of types which are submitted with crash pings.
Currently crash report annotations can come from anywhere in our code and we don't know what types of data may be recorded. As we make upcoming changes to crash reports, I'd like us to be more deliberate about metadata, and I hope this will improve everyone's access patterns. See the user story for problems to solve. Some of these problems may be more complex than others and may need future dependent bugs.
User Story: (updated)
I was thinking about this during one of the uptime meetings last week as well. I was considering a simpler solution where we would just have a description along with the annotation key, like
```
CRASHREPORTER_ANNOTATION(StartupCrash, "If set to '1', indicates that the crash happened during the startup process")
```

But yeah, there's a lot more information we could attach here. Whether the annotation is privacy sensitive would be a very useful one. If we listed them all in a YAML file we'd have to generate a header file at build time, and some sort of JS-equivalent, but that ought to be fairly straightforward.
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #1)
> But yeah, there's a lot more information we could attach here. Whether the
> annotation is privacy sensitive would be a very useful one. If we listed
> them all in a YAML file we'd have to generate a header file at build time,
> and some sort of JS-equivalent, but that ought to be fairly straightforward.

Yes, I had thought the same thing. If the various annotations would also be flagged as privacy-sensitive or not then we could also generate the crash ping annotation whitelist automatically. That would greatly reduce the risk of accidentally putting something privacy-sensitive in the ping.

BTW in one of my patches I've extensively documented what we put in the crash ping by scouring the code in the exception handler and in other places [1]. However keeping the doc manually in sync with the code is obviously error-prone.

[1] https://gecko.readthedocs.io/en/latest/toolkit/components/telemetry/telemetry/data/crash-ping.html
gsvelto has patches in bug 1348273!
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.