Closed Bug 712759 Opened 14 years ago Closed 14 years ago

[stage] [prod] Advanced search result counts differ for 'All' and 'multi-select' queries

Categories

(Socorro :: General, task, P1)

Product:
Socorro
Component:
General
Type:
task

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: mbrandt, Assigned: rhelmer)

Details

(Whiteboard: [stage] [prod])

Attachments

(1 file)

qa - verified
90.35 KB, image/png
Details
There is a slight difference between searching for "All" and doing a multi-select for all versions. This is on stage and prod so I think it's an existing bug. Steps to reproduce: 1. goto advanced search 2. select product Fennec > version All 3. click filter results and see count 4. goto advanced search 5. select product Fennec > highlight all version 6. click filter results and see count Expected: results counts should match All: https://crash-stats.allizom.org/query/query?product=Fennec&version=ALL%3AALL&range_value=1&range_unit=weeks&date=12%2F21%2F2011+13%3A21%3A41&query_search=signature&query_type=contains&query=&reason=&build_id=&process_type=any&hang_type=any&do_query=1 Multi-select: https://crash-stats.allizom.org/query/query?product=Fennec&version=Fennec%3A9.0%28beta%29&version=Fennec%3A9.0b6&version=Fennec%3A9.0b5&version=Fennec%3A9.0b4&version=Fennec%3A9.0b3&version=Fennec%3A9.0b2&version=Fennec%3A9.0b1&version=Fennec%3A9.0&version=Fennec%3A8.0%28beta%29&version=Fennec%3A8.0b6&version=Fennec%3A8.0b5&version=Fennec%3A8.0&version=Fennec%3A7.0.1&version=Fennec%3A7.0&version=Fennec%3A6.0.2&version=Fennec%3A6.0.1&version=Fennec%3A12.0a1&version=Fennec%3A11.0b1&version=Fennec%3A11.0a2&version=Fennec%3A11.0a1&version=Fennec%3A11.0&version=Fennec%3A10.0a2&range_value=1&range_unit=weeks&date=12%2F21%2F2011+13%3A21%3A41&query_search=signature&query_type=contains&query=&reason=&build_id=&process_type=any&hang_type=any&do_query=1
So, let me explain what happens in there. When searching for "All" versions of a product, there is simply no filtering at all. We get all crash reports from the reports table whatever there version, build_id, release_channel... When searching for all versions available in the UI, we do filter by version, build_id and release_channel. Search is using data from the product_info and product_versions tables to do that filtering. Basically we have a huge list of clauses, one for each version, linked by OR conditions. My theory is that we somehow have, in the reports table, crash reports that do not belong to any of the known versions. Or data in product_info is not complete. I don't know if any of those are possible. Maybe my code is simply doing something wrong... :) I will investigate this tomorrow and let you know what I discover.
Well, I'd expect those queries to give different results, as "All" probably also returns results for those versions that are not in the "active" set any more, and the query page only shows that set in the list.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #3) > Well, I'd expect those queries to give different results, as "All" probably > also returns results for those versions that are not in the "active" set any > more, and the query page only shows that set in the list. I thought of this too, but we first noticed this on stage while testing the new FennecAndroid product, which has all active releases and only a few days of (test) data, and there is a discrepancy. Could be a separate issue but seems worth understanding.
(In reply to Robert Helmer [:rhelmer] from comment #4) > I thought of this too, but we first noticed this on stage while testing the > new FennecAndroid product, which has all active releases and only a few days > of (test) data, and there is a discrepancy. > > Could be a separate issue but seems worth understanding. Oh, in this case, sure.
I investigated a bit, and it seems my first theory is right. When I do a minus between the first query (get 'All' versions) and the second (get all listed versions), here the list of versions I find: version --------- 7.0 4.0.1 4.0b3 4.0b4 4.0b2 6.0.2 6.0 5.0 4.0 10.0a1 4.0b5 The queries assumed the product was Fennec, and use the same date range. None of those versions is in the current list of versions for Fennec. This was performed in my dev instance with the most recent minidump (2011Dec12). I don't know if this is an expected behavior but I guess it is. It seems there is no bug in the code as we don't get in that result any version numbers that are in the selected list.
Component: Socorro → General
Product: Webtools → Socorro
(In reply to Adrian Gaudebert [:adrian] from comment #6) > I investigated a bit, and it seems my first theory is right. When I do a > minus between the first query (get 'All' versions) and the second (get all > listed versions), here the list of versions I find: I agree that this is a factor, but we saw this on stage when we had just added new (test) releases on stage and there were no older releases (this was for the new FennecAndroid product). The links in the first few comments talk about Fennec rather than FennecAndroid so I think we're conflating the two things here. I'll take this and see if I can make a reproducible test case.
Assignee: nobody → rhelmer
Status: NEW → ASSIGNED
Priority: -- → P1
Haven't reproduced locally with a fake DB yet, but you can see this on stage (or prod) right now: FennecAndroid, "all", 574 results: https://crash-stats.allizom.org/query/query?product=FennecAndroid&version=ALL%3AALL&range_value=1&range_unit=weeks&date=12%2F30%2F2011&query_search=signature&query_type=contains&query=&reason=&build_id=&process_type=any&hang_type=any&do_query=1 FennecAndroid, all versions multi-selected, 565 results: https://crash-stats.allizom.org/query/query?product=FennecAndroid&version=FennecAndroid%3A12.0a1&version=FennecAndroid%3A11.0a2&version=FennecAndroid%3A11.0a1&range_value=1&range_unit=weeks&date=12%2F30%2F2011&query_search=signature&query_type=contains&query=&reason=&build_id=&process_type=any&hang_type=any&do_query=1 This is a new product and there are no expired versions, so I think this is something different than comment 6. I'll point my dev instance at stage and see what queries are generated for these.
(In reply to Robert Helmer [:rhelmer] from comment #8) > Haven't reproduced locally with a fake DB yet, but you can see this on stage > (or prod) right now: > > FennecAndroid, "all", 574 results: > > https://crash-stats.allizom.org/query/ > query?product=FennecAndroid&version=ALL%3AALL&range_value=1&range_unit=weeks& > date=12%2F30%2F2011&query_search=signature&query_type=contains&query=&reason= > &build_id=&process_type=any&hang_type=any&do_query=1 /* socorro.search.Search search */ SELECT r.signature, count(r.id) as total, count(CASE WHEN (r.os_name = E'Windows NT') THEN 1 END) AS is_windows, count(CASE WHEN (r.os_name = E'Mac OS X') THEN 1 END) AS is_mac, count(CASE WHEN (r.os_name = E'Linux') THEN 1 END) AS is_linux, SUM (CASE WHEN r.hangid IS NULL THEN 0 ELSE 1 END) AS numhang, SUM (CASE WHEN r.process_type='plugin' THEN 1ELSE 0 END) as numplugin, SUM (CASE WHEN r.process_type='content' THEN 1ELSE 0 END) as numcontent FROM reports r WHERE r.date_processed BETWEEN '2011-12-23T00:00:00' AND '2011-12-30T00:00:00' AND (r.product=E'FennecAndroid') GROUP BY r.signature ORDER BY total DESC LIMIT 100 OFFSET 0 > > FennecAndroid, all versions multi-selected, 565 results: > > https://crash-stats.allizom.org/query/ > query?product=FennecAndroid&version=FennecAndroid%3A12. > 0a1&version=FennecAndroid%3A11.0a2&version=FennecAndroid%3A11. > 0a1&range_value=1&range_unit=weeks&date=12%2F30%2F2011&query_search=signature > &query_type=contains&query=&reason=&build_id=&process_type=any&hang_type=any& > do_query=1 /* socorro.search.Search search */ SELECT r.signature, count(r.id) as total, count(CASE WHEN (r.os_name = E'Windows NT') THEN 1 END) AS is_windows, count(CASE WHEN (r.os_name = E'Mac OS X') THEN 1 END) AS is_mac, count(CASE WHEN (r.os_name = E'Linux') THEN 1 END) AS is_linux, SUM (CASE WHEN r.hangid IS NULL THEN 0 ELSE 1 END) AS numhang, SUM (CASE WHEN r.process_type='plugin' THEN 1ELSE 0 END) as numplugin, SUM (CASE WHEN r.process_type='content' THEN 1ELSE 0 END) as numcontent FROM reports r WHERE r.date_processed BETWEEN '2011-12-23T00:00:00' AND '2011-12-30T00:00:00' AND (r.product=E'FennecAndroid') AND ((r.product=E'FennecAndroid' AND r.release_channel ILIKE 'Nightly' AND r.version=E'12.0a1') OR (r.product=E'FennecAndroid' AND r.release_channel ILIKE 'Aurora' AND r.version=E'11.0a2') OR (r.product=E'FennecAndroid' AND r.release_channel ILIKE 'Nightly' AND r.version=E'11.0a1')) GROUP BY r.signature ORDER BY total DESC LIMIT 100 OFFSET 0
(In reply to Robert Helmer [:rhelmer] from comment #8) > I'll point my dev instance at stage and see what queries are generated for > these. My opinion here, if it is not due to non-current versions, is that product_info and/or product_versions tables are not up-to-date. The code that generates data about each version is in ``socorro/external/postgresql/util.py``, class Util, method versions_info(). If what I do in there is correct, then my next suggestion would be to check ``socorro/external/postgresql/search.py`` from line 158 to 177 and the ``generate_version_where()`` method from line 392 to end of file. jberkus helped me write this algorithm though, so I doubt it is wrong unless I misunderstood something or something changed in the DB.
OK so in this case it's "default" channel crashes: breakpad=> select release_channel, version from reports where product='FennecAndroid' and date_processed BETWEEN '2011-12-23T00:00:00' AND '2011-12-30T00:00:00' group by version, release_channel; release_channel | version -----------------+--------- default | 12.0a1 aurora | 11.0a2 nightly | 11.0a1 nightly | 12.0a1 default | 11.0a1 (5 rows) If we want these (and any broken/bogus crashes) to show up for "All" (which is reasonable I think) then this is fine. Glad that we understand what's going on though. Kairo, any opinion there? Please WONTFIX if this is ok/expected.
(In reply to Robert Helmer [:rhelmer] from comment #11) > OK so in this case it's "default" channel crashes Ah, makes sense to show those for "All" but not for the specific versions, yes. Maybe that should become clear from something mentioned in the UI as well, though.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #12) > (In reply to Robert Helmer [:rhelmer] from comment #11) > > OK so in this case it's "default" channel crashes > > Ah, makes sense to show those for "All" but not for the specific versions, > yes. Maybe that should become clear from something mentioned in the UI as > well, though. Hmm thinking about how to do this, here is what is printed when a few versions are selected: Results within 1 weeks of 01/04/2012, and the product is one of Firefox, and the version is one of Firefox:12.0a1, Firefox:11.0a2 and the crashing process was of any type. And for "all": Results within 1 weeks of 01/04/2012, and the product is one of Firefox and the crashing process was of any type. Perhaps we could append something about how this result includes development and other non-release versions.
(In reply to Robert Helmer [:rhelmer] from comment #13) > Perhaps we could append something about how this result includes development > and other non-release versions. "non-release" is probably not the right term, perhaps "unofficial".
Target Milestone: 2.4 → 2.4.1
Just changed the wording, r? https://github.com/mozilla/socorro/pull/292
Commits pushed to https://github.com/mozilla/socorro https://github.com/mozilla/socorro/commit/f426327fc9a1798d1f7d411cae90886f0378833f bug 712759 - note that 'all' includes unofficial builds https://github.com/mozilla/socorro/commit/ab618d14fdd79d28455fa33a33cc63e7afe319e8 Merge pull request #292 from rhelmer/bug712759-advanced-search-unofficial-builds bug 712759 - note that 'all' includes unofficial builds
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Verified on stage, the string has been updated to read "and the crashing process was of any type (including unofficial release channels)."
Status: RESOLVED → VERIFIED
Attached image qa - verified —
screenshot with new text.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: