Bug 1719232 is an example of a crash that's only happening because a distro is building with compiler flags that we don't support. Bug 1725575 may be another example of a crash like this.

It would be very helpful to quickly distinguish between crashes on the builds that we create and crashes on non-official builds.

Any idea how we could differentiate between builds we did and builds we didn't do? Is there something in the crash annotations that indicates one way or the other?

Perhaps we could use the debug identifier for libxul and maintain a list of libxul debug identifiers for official builds. Gabriele do you have a suggestion for a good approach?

Crash report > Telemetry Environment > distributionId

• canonical
• mint
• peppermint

https://crash-stats.mozilla.org/report/index/21587801-fddf-448c-b110-dcad10210813#tab-telemetryenvironment

"partner": {
    "distributionId": "canonical",
    "distributionVersion": "1.0",
    "partnerId": "ubuntu",
    "distributor": "canonical",
    "distributorChannel": "ubuntu",
    "partnerNames": [
        "ubuntu"
    ]
},

Crash reports of official Mozilla binaries have:

partner": {
    "distributionId": null,
    "distributionVersion": null,
    "partnerId": null,
    "distributor": null,
    "distributorChannel": null,
    "partnerNames": [ ]
},

Yeah, even just getting distributionId as database field that you could aggregate on might be good enough.

Redirecting the NI? to Will because he's the one doing the database heavy lifting in Socorro, I only tweak the stack walker from time to time :-)

So far we have two options:

Option 1: We could maintain a list of official build debug ids. I think we'd have to change the upload symbols step in the build process to set a flag saying "this is an official build" or something along those lines such that Tecken (the symbols server) could keep track of which builds were official and which weren't. Socorro (crash ingestion and Crash Stats) could query Tecken for the official list of debug ids and when those symbols show up in crash reports, Socorro could mark the crash report as "official".

Option 2: We could uplift the distributionid data. Socorro could add a processor rule that extracts that value if it exists and makes it part of the processed crash. If there's no TelemetryEnvironment or that field isn't in the TelemetryEnvironment, we use "unknown" as the value. If the value is null, we use "mozilla". Then this aggregates as:

• distributorid -- if it exists and is non-null
• "mozilla" -- if it exists and is null
• "unknown" -- if it doesn't exist

Of those two options, option 2 seems much simpler to implement plus I can do it myself without coordinating with anyone.

Jeff: Does that sound ok? Do you have any thoughts on the values: distributorid, "mozilla", and "unknown"?

That sounds good to me.

Grabbing this one to do as laid out in comment 6.

willkg merged PR #5870: "bug 1732414: extract distributionId" in 4d4006f.

I pushed this to production in bug #1733472.

Socorro will build a new Elasticsearch index with the new field this weekend. It'll start accumulating data at that point and will be usable for aggregations and the like.

I'll keep this open and check it on Monday.

I see data and it works with aggregations and searching, so I think we're good here. Marking as FIXED.

Thanks!