1150662 - 'platform' not always known in supersearch results

Status: RESOLVED INACTIVE

(Socorro :: Webapp, task)

Description

[Peter Bengtsson [:peterbe]]

Sometimes, the new supersearch backed report list gets crashes that don't have a 'platform' key.

Comment 1

[Peter Bengtsson [:peterbe]]

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.

Comment 2

[Peter Bengtsson [:peterbe]]

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

Comment 3

[Peter Bengtsson [:peterbe]]

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

Comment 4

[Robert Kaiser]

platform was empty in some results in Postgres as well, mostly for crashes that have a missing/empty or corrupted minidump.

Comment 5

[Robert Helmer [:rhelmer]]

(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.

Comment 6

[Robert Kaiser]

(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.

Comment 7

[Robert Helmer [:rhelmer]]

(In reply to Robert Kaiser (:[e-mail]) 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

[Robert Kaiser]

(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.

Comment 9

[Will Kahn-Greene [:willkg] ET needinfo? me]

I'm going to close this for inactivity. If it's still an issue, please reopen with details and examples.