'platform' not always known in supersearch results

NEW
Unassigned

Status

Socorro
Webapp
3 years ago
3 years ago

People

(Reporter: peterbe, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

3 years ago
Sometimes, the new supersearch backed report list gets crashes that don't have a 'platform' key.
(Reporter)

Comment 1

3 years ago
Rob, or Lars, 
Which fields are the only fields we can expect in every supersearch query?

When we used to drive the report list based on postgres we knew for sure which columns would always come back (empty or not empty) but this is no longer the case as ES is basically copies of the processing.
Flags: needinfo?(rhelmer)
Flags: needinfo?(lars)
(Reporter)

Comment 2

3 years ago
I can not reproduce this in any way on stage. And I've randomly clicked A LOT of signatures :)
(Reporter)

Comment 3

3 years ago
Also, it seems the problem has suddenly gone away on the URL captured in sentry.

Comment 4

3 years ago
platform was empty in some results in Postgres as well, mostly for crashes that have a missing/empty or corrupted minidump.
(In reply to Peter Bengtsson [:peterbe] from comment #1)
> Rob, or Lars, 
> Which fields are the only fields we can expect in every supersearch query?
> 
> When we used to drive the report list based on postgres we knew for sure
> which columns would always come back (empty or not empty) but this is no
> longer the case as ES is basically copies of the processing.

The bare minimum fields collector insists on are ProductName and Version. A crash without a minidump in the upload_file_minidump field will not actually make it through the processor, a corrupt minidump will make it through but not add any useful fields.

For crashes with valid minidumps, I don't think there's really any guarantee what fields are present. You should be defensive.
Flags: needinfo?(rhelmer)
Flags: needinfo?(lars)

Comment 6

3 years ago
(In reply to Robert Helmer [:rhelmer] from comment #5)
> The bare minimum fields collector insists on are ProductName and Version. A
> crash without a minidump in the upload_file_minidump field will not actually
> make it through the processor, a corrupt minidump will make it through but
> not add any useful fields.

Er, we definitely have crashes without a minidump listed in reports and stuff, the processor gives them one of the "EMPTY: xxx" signatures, I don't remember which one.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #6)
> (In reply to Robert Helmer [:rhelmer] from comment #5)
> > The bare minimum fields collector insists on are ProductName and Version. A
> > crash without a minidump in the upload_file_minidump field will not actually
> > make it through the processor, a corrupt minidump will make it through but
> > not add any useful fields.
> 
> Er, we definitely have crashes without a minidump listed in reports and
> stuff, the processor gives them one of the "EMPTY: xxx" signatures, I don't
> remember which one.

Yes, but the upload_file_minidump field was specified to collector (even if a 0-byte file was actually supplied). This is distinct from not providing the upload_file_minidump field at all.

Comment 8

3 years ago
(In reply to Robert Helmer [:rhelmer] from comment #7)
> Yes, but the upload_file_minidump field was specified to collector (even if
> a 0-byte file was actually supplied). This is distinct from not providing
> the upload_file_minidump field at all.

Ah, OK. I'd be interested if we get reports that completely miss this field right now. If we do *and* ignore those crashes, it sounds like a bug.
You need to log in before you can comment on or make changes to this bug.