Closed Bug 1100790 Opened 11 years ago Closed 1 year ago

[Super Search] Combining platforms Mac OS X and Linux gives no mac results

Categories

(Socorro :: Webapp, defect, P2)

Product:
Socorro
Component:
Webapp
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: adrian, Assigned: willkg)

Details

Attachments

(3 files, 1 obsolete file)

[mozilla-services/socorro] bug-1100790: fix super search platform queries (#6647)
53 bytes, text/x-github-pull-request
Details | Review
[mozilla-services/socorro] bug-1100790: revert original changes (#6661)
53 bytes, text/x-github-pull-request
Details | Review
[mozilla-services/socorro] bug-1100790: change supersearch terms query to matches (#6690)
53 bytes, text/x-github-pull-request
Details | Review
For example: https://crash-stats.mozilla.com/search/?platform=Mac+OS+X&platform=Linux&_facets=platform The facet shows there are only Linux results. But if we remove Linux from the search: https://crash-stats.mozilla.com/search/?platform=Mac+OS+X&_facets=platform\ Suddenly Mac results appear. I don't know why this is happening but I suspect the white spaces in 'Mac OS X' are involved.
Priority: P1 → P3
This is happening because of the white space in "Mac OS". Because there is one, the query turns into a "match phrase" elasticsearch filter, which doesn't work with the other regular "terms" filters.
Assignee: adrian → nobody
I could not reproduce this issue. Is this issue still reproducible?
Flags: needinfo?(adrian)
I can still reproduce, just by clicking the first link in the comment. There should be Mac results in the platform facet, and they don't show up.
Flags: needinfo?(adrian)
Thanks for your reply! :adrian I found that "Mac+OS+X" doesn't work but "Mac OS X" works as a query parameter. This hits Windows and Linux result. https://crash-stats.mozilla.com/search/?platform=Windows&platform=Linux&_facets=platform This hits Mac OS X result. https://crash-stats.mozilla.com/search/?platform=Mac%20OS%20X&_facets=platform This hits ONLY Linux result. https://crash-stats.mozilla.com/search/?platform=Mac%20OS%20X&platform=Linux&_facets=platform The 3rd URL should hit Linux and Mac OS X.

I was about to file a new bug and I found this one. The issue is still present, take this query for example. The "Platform" facet will only show Linux and Windows crashes. If we narrow it down to "Mac OS X" only tough we get a few crashes for that platform.

Grabbing this to look at soon.

Assignee: nobody → willkg
Status: NEW → ASSIGNED
Type: task → defect
Priority: P3 → P2

There are a couple of problems.

First, I think the platform field is indexed wrong. It's indexed as an analyzed string, but should probably be indexed as a keyword.

Second, when there's only one value and it has a space in it, the super search code uses a simple_query_string query wrapped in a filter. If there's more than one value, then it uses a terms filter. These are completely different things. Specifying Mac OS X vs. [Mac OS X, Linux, Windows] creates two different searches and they behave differently. It's been this way since support for years and years. There's no explanation for why it was implemented this way or what the requirements were for the implementation.

We have to do some experimenting to figure out how to fix this in a backward compatible way with existing behavior for fields.

willkg merged PR [mozilla-services/socorro]: bug-1100790: fix super search platform queries (#6647) in 2df8d42.

On Friday, GitHub Actions weren't working, so I did other things.

Then today, I spent an hour writing a test harness that does this:

  1. fetches all the known supersearch fields
  2. for each field
    1. does a facet to get the top 3 values
    2. for each value
      1. does a supersearch using the default operator ('has terms" before this PR lands and "matches" after this PR lands) for 3 results and prints out the uuid and value
    3. does a superssearch using the default operator ("has terms" before this PR lands and "matches" after this PR lands) for all three values and prints out the uuid and value

This gives us a baseline of results before and after the change. It's hard coded to look at date >= 2024-06-24 < 2024-06-25 and at stage.

I'll run it before and after the stage auto deploy and compare the results. Depending on what happens, I'll either:

  1. cheer because everything is super duper!
  2. fix some additional things in followup PRs
  3. back this out because it needs some more thinking

I did another PR that fixes a bunch of other fields that are currently broken in prod and didn't get any better with my previous PR. After this second change, the following fields now all work with "match" operator:

  • crash_report_keys
  • mac_memory_pressure
  • xpcom_spin_event_loop_stack
  • crashing_thread_name
  • android_version

I wrote up bug #1905772 to fix android_model which is indexed poorly.

I didn't see any fields get worse with the "match" change, so I'm going to keep moving forward.

Before this goes to production, we should send out a heads-up about how the default operator is changing even if it's in a way that makes it more reliable and less flaky.

crashing_thread_name working correctly is going to be super-useful, thanks!

This is my supersearch query test harness. I can't post the data because it includes protected data.

https://github.com/willkg/socorro-supersearch-test

I ran out of time. I'm backing out the first change and I'll redo that one and the second change when I get back from PTO.

Attachment #9410703 - Attachment is obsolete: true

This was deployed in bug 1906174 just now.

Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED

We reverted the changes for this bug, so no changes were deployed in 2024.07.03. I'll redo them this week.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

willkg merged PR [mozilla-services/socorro]: bug-1100790: change supersearch terms query to matches (#6690) in 1c39163.

I need to notify stability and crashreporting-wg about this change before it goes to prod.

I emailed stability and crash-reporting-wg mailing lists. I included examples of how the change affects queries. This fixes a ton of weird behavior.

I went through and tested stage:

  • supersearch seems to be working fine--I'm getting results I expect
  • signature report looks fine--I'm not seeing any errors; results are what I would expect
  • topcrashers report looks fine--I'm not seeing any errors; results are what I would expect

I think this is good to go to prod.

This went to prod just now in bug #1915150. Marking as FIXED.

Status: REOPENED → RESOLVED
Closed: 1 year ago → 1 year ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: