940770 - crashes/frequency -- should it be talking to 'reports' or 'reports_clean' ?

Status: RESOLVED WONTFIX

(Socorro :: Webapp, task)

Description

[Selena Deckelmann :selenamarie :selena]

Liz reported today a discrepancy in data shown on summary pages and what is shown in the 'Table' tab for Signature Summary.

After some sleuthing, it turns out that Table tab data is populated from crashes/frequency (in socorro/external/postgresql/crashes.py)

Is this intentional? 

If not, let's change the query. 

If so, let's change the documentation to reflect that the data in that table might differ from our de-duplicated reports_clean data.

Comment 1

[Robert Helmer [:rhelmer]]

I know that this was an intentional choice in the past for /report/list (which is the only place the crashes/frequency middleware service is used in the frontend) to show real-time data, which is why it's always been based on reports table and not a matview.

This thinking predated the existence of the reports_clean table, so I am not sure if an up-to-one-hour delay that using reports_clean would imply is acceptable for this service or not.

Comment 2

[Peter Bengtsson [:peterbe]]

A LOT of code uses reports instead of reports_clean::

(socorro)peterbe@mpb:~/dev/MOZILLA/SOCORRO/socorro (master %=)$ gg '\.build_reports_sql_from' | grep -v unittest
socorro/external/postgresql/crashes.py:101:        sql_from = self.build_reports_sql_from(params)
socorro/external/postgresql/crashes.py:403:        sql_from = self.build_reports_sql_from(params)
socorro/external/postgresql/report.py:160:        sql_from = self.build_reports_sql_from(params)
socorro/external/postgresql/search.py:105:        sql_from = self.build_reports_sql_from(params)

If we know exactly which should use reports and which should use reports_clean it'll be easy to get them all right in on sweep.

Comment 3

[Robert Kaiser]

Nowadays, we definitely should match the signature summary with the Table and Graph tabs, including that we're only showing crashes for that specific version(s) and time period filter that is selected for this report/list.

What Liz pointed to (i.e. clicking on the #4 topcrash on 28.0a1, which is gfxContext::PushClipsToDT and currently https://crash-stats.mozilla.com/report/list?product=Firefox&range_value=7&range_unit=days&date=2013-11-19&signature=gfxContext%3A%3APushClipsToDT%28mozilla%3A%3Agfx%3A%3ADrawTarget*%29&version=Firefox%3A28.0a1 as the actual URL) definitely feels like a regression, i.e. like we wouldn't apply the version filter any more to this tab (which we did previously).

I don't care too much how it's implemented behind the scenes but using reports_clean sounds like the right thing to do here.

That said and probably a different issue, we probably should mention on the Graph and Table tabs that they are always by build date and not by crash date (which is helpful but not signed out anywhere).

Comment 4

[Liz Henry (:lizzard) (relman/hg->git project)]

The information I wanted to know was whether a particular build caused most of the crashes. I found myself typing "In the last 7 days, this crash signature was reported for 461 crashes, 840 of which were from build 2013111408" or something like that. 

Of course that didn't make sense, since any crashes that happened for that build would have been within 7 days of my query and so should have been counted in the total crashes on the signature summary tab.

Comment 5

[Tracy Walker [:tracy]]

Liz, those spikes we're seeing are from particular beta build dates. If I'm looking at a table for crash data for 27.0a2, I don't want to see crashes from Nightly or Betas included. That exactly what's happening here.  If reports_clean correctly filters by version/channel, then yes, that's what we want.

Comment 6

[Peter Bengtsson [:peterbe]]

Can we not just use SuperSearch instead?

Comment 7

[[DEACTIVATED] Adrian Gaudebert]

Crashes frequency is only used by ReportList, when that is removed we will also remove that service. There is no need to work on this bug.