Make "is" searches work on 'mac_crash_info'
Categories
(Socorro :: General, defect, P2)
Tracking
(Not tracked)
People
(Reporter: smichaud, Assigned: willkg)
References
Details
Attachments
(1 file)
Currently (at crash-stats.mozilla.org) an "is" search on "mac crash info" returns no results, even if matching crash reports do exist:
A "contains" search also fails if the search criterion is the entire "mac crash info" record:
Can we make these searches work? Otherwise it won't be possible to search for crash reports by clicking on an item in a list "faceted" on "mac crash info".
|
Assignee | |
Comment 1•4 years ago
|
||
The "is" query does a term filter against the ".full" value. I'm not sure what's going on. I'll have to look into it.
|
|
Assignee | |
Comment 2•3 years ago
|
||
I tinkered with this a little today. My current hunch is that this is a problem with whitespace matching. When the processor extracts the value from json_dump, it encodes the structure as JSON in a way that's good for display, but probably bad for indexing and searching.
I'll test out my hunch tomorrow.
|
|
Assignee | |
Comment 3•3 years ago
|
||
I verified it's a problem with the whitespace. Also, there's this annoying thing where if you're going from a "mac_crash_info exists" supersearch and then click on a value to refine the search, you end up with a supersearch doing "mac_crash_info exists" and "mac_crash_info is <somevalue>". When that happens, supersearch is doing an OR between those filters because it's for the same field--you're getting "mac_crash_info exists OR mac_crash_info is <somevalue>". That's unhelpful.
I'm going to fix "is" for mac_crash_info by removing the whitespace in the indexed value. Then what you're doing will mostly work. You'll need to manually remove the "mac_crash_info exists" filter from the refined query.
I'm going to defer fixing the "we shouldn't mix exists with is for the same field" issue to a new bug.
|
|
Assignee | |
Comment 4•3 years ago
|
||
|
|
Assignee | |
Comment 5•3 years ago
|
||
|
|
Assignee | |
Comment 6•3 years ago
|
||
This deployed a little bit ago in bug #1749582.
I'm still working on a fix for bug #1749561. Also, this changes how the data is extracted from json_dump, so we'd need to reprocess affected crash reports. It looks like there are a fair number of crash reports with mac_crash_info.
Steven: I can reprocess crash reports. How far back do you want me to reprocess?
|
Reporter | |
Comment 7•3 years ago
|
||
Steven: I can reprocess crash reports. How far back do you want me to reprocess?
Part of me wants to say "all of them" -- in other words go back six months.
Is that reasonable? If not, then I leave the decision up to you.
(Of course you'd only need to reprocess reports that actually contain (non-empty) mac_crash_info.)
|
|
Assignee | |
Comment 8•3 years ago
|
||
I reprocessed all the crash reports with mac_crash_info. Marking as FIXED.
|
|
Reporter | |
Comment 9•3 years ago
|
||
I did a quick test of this, by doing a "mac_crash_info exists" search, faceting on mac_crash_info, then right-clicking on one of the "facets". I did have to remove the original "mac_crash_info exists" line (now redundant, bug 1749561). But afterwards everything was as expected.
Thanks!
Description
•