crash report vs. crash ping¶
We have two different methods of collecting crash data.
- crash report
The crash reporter assembles a crash report with crash annotations and minidumps and some other things. It prompts the user for permission to submit the crash report. If the user says “yes”, then the crash reporter submits it to the crash ingestion pipeline where it’s collected, processed, and available in Crash Stats.
Crash report data is off by default.
Crash report data contains protected data which includes sensitive data, PII, etc.
Not all crashes result in a crash report sent to the crash ingestion pipeline for various technical reasons.
Not all users say “yes” to submit the crash report.
The crash ingestion pipeline throttles crash reports. For example, it only accepts 10% of incoming Firefox desktop release channel crash reports and rejects the rest.
- Collector throttle rules:
- crash ping
The crash reporter walks the stack and assembles a crash ping which a subset of crash annotation data. It sends this using Telemetry clients to the Telemetry data ingestion pipeline. It is available in the
Crash ping data is on by default and shares opt-out mechanisms with Telemetry data submission.
Crash ping data does not contain protected data.
As of 2022-10-18, we only support crash ping data with Firefox.
- Crash ping documentation:
- Older blog post on crash reports vs. crash pings (2019):
Updating crash ping schema¶
After someone has added a new field to CrashAnnotations.yaml
ping: true in it, we do the following:
From a mozilla-pipeline-schemas (https://github.com/mozilla-services/mozilla-pipeline-schemas/) checkout, run:
If any exist, you will get a list of crash annotations that are contained in the ping but are not yet in the schema.
Add the annotation to
Follow https://github.com/mozilla-services/mozilla-pipeline-schemas#cmake-build-instructions to build the schema files.
Create a pull request against the main branch in mozilla-pipeline-schemas referencing that bug.