fyi: Crash Stats Top Crashers report will soon filter on report type

156 views
Skip to first unread message

William Kahn-Greene

unread,
Jul 17, 2023, 8:21:47 AM7/17/23
to stability, crash-reporting-wg
(cc: stability, crash-reporting-wg)

Hi!

This covers a major change to how the Top Crashers report on Crash Stats works that will take effect next week.

We're changing the Top Crashers report so that you can filter the report by "report type". The value domain for "report type" is "crash" and "hang". The goal is to make it easier to see just crashes in the Top Crashers report without the plethora of hang crash reports.

In order to implement this, I had to add a new indexed field. A new index has been created and is being indexed for newly processed crash reports in the stage environment. You can tinker with it here. Note that only crash reports processed since July 16th or whenever the index was created are affected by the filter.


image.png


Currently, the filter defaults to report_type="Any". In a month, we'll have enough data to switch that to default to report_type="crash".

I'm hoping to push this code to production this week. Then a new index will get created over the weekend and the filter will start working next week.

The work is being done in this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1667997

Any questions or concerns, please let me know.

/will

Gabriele Svelto

unread,
Jul 21, 2023, 11:28:55 AM7/21/23
to William Kahn-Greene, stability, crash-reporting-wg
Thanks Will,
this is a fantastic improvement! I've tried using the `report_type`
field in SuperSearch and for now I can't find crashes that have the
field populated, is this expected?

Gabriele

On 17/07/23 14:21, William Kahn-Greene wrote:
> (cc: stability, crash-reporting-wg)
>
> Hi!
>
> This covers a major change to how the Top Crashers report on Crash Stats
> works that will take effect next week.
>
> We're changing the Top Crashers report so that you can filter the report
> by "report type". The value domain for "report type" is "crash" and
> "hang". The goal is to make it easier to see just crashes in the Top
> Crashers report without the plethora of hang crash reports.
>
> In order to implement this, I had to add a new indexed field. A new
> index has been created and is being indexed for newly processed crash
> reports in the stage environment. You can tinker with it here. Note that
> only crash reports processed since July 16th or whenever the index was
> created are affected by the filter.
>
> https://crash-stats.allizom.org/topcrashers/?product=Firefox&version=115.0.2 <https://crash-stats.allizom.org/topcrashers/?product=Firefox&version=115.0.2>
>
> image.png
>
>
> Currently, the filter defaults to report_type="Any". In a month, we'll
> have enough data to switch that to default to report_type="crash".
>
> I'm hoping to push this code to production this week. Then a new index
> will get created over the weekend and the filter will start working next
> week.
>
> The work is being done in this bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1667997
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1667997>
>
> Any questions or concerns, please let me know.
>
> /will
>
> --
> You received this message because you are subscribed to the Google
> Groups "crash-reporting-wg" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to crash-reporting...@mozilla.com
> <mailto:crash-reporting...@mozilla.com>.
> To view this discussion on the web visit
> https://groups.google.com/a/mozilla.com/d/msgid/crash-reporting-wg/CAKnh9qgT%2BRxP6jaEXS219Oh0YBU%2Bz4FCkdeZ5_ADp%3DFE9jZ3FA%40mail.gmail.com <https://groups.google.com/a/mozilla.com/d/msgid/crash-reporting-wg/CAKnh9qgT%2BRxP6jaEXS219Oh0YBU%2Bz4FCkdeZ5_ADp%3DFE9jZ3FA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/a/mozilla.com/d/optout
> <https://groups.google.com/a/mozilla.com/d/optout>.

OpenPGP_signature

Gabriele Svelto

unread,
Jul 21, 2023, 11:30:25 AM7/21/23
to William Kahn-Greene, stability, crash-reporting-wg
Scratch my previous e-mail, I've just read on the bug that we need to
wait on Monday for the indexes to be repopulated. I can't wait to use
this to make nightly crash triage easier!

Gabriele
OpenPGP_signature

William Kahn-Greene

unread,
Jul 21, 2023, 11:56:51 AM7/21/23
to Gabriele Svelto, stability, crash-reporting-wg
The timeline for when things work for these kinds of changes is hard to describe and confusing. At some point, I'll figure out a general way to explain these changes better.

Let me know if this is more helpful:

All the code changes have been deployed to the production environment. However, the Top Crashers report type filter depends on data being in the `report_type` field in the index. That won't start happening until July 24th when a new index is created. We don't backfill data in crash ingestion, so crash reports collected and processed on or after July 24th will have data in the report_type field--crash reports collected before July 24th will not.

The Top Crashers report has several date ranges you can look at; the default is 7 days and the longest is 28 days.

Given all that, here's roughly what you can expect timeline-wise:

* prior to July 24th: the Top Crashers report type filter doesn't work. "Any" is like our previous behavior with a mix of crash and hang reports. "crash" and "hang" will have no reports.
* July 25th: Top Crashers report type filter works as expected if the range you're looking at is 1 day.
* July 27th: Top Crashers report type filter works as expected for ranges 1 day and 3 days.
* July 31st: Top Crashers report type filter works as expected for ranges 1 day, 3 days, and 7 days (the default).
* August 21st: Top Crashers report type filter works as expected for all ranges.

After August 21st, I'll change the default value for report type filter to "crash". That's covered in bug 1844174.

Hope that helps!

/will

Reply all
Reply to author
Forward
0 new messages