789526 - Empty, non-plotted graphs for signatures in topcrasher by build date

Status: VERIFIED FIXED

(Socorro :: Webapp, task)

Description

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: Screenshot

STR:

1. Load https://crash-stats.allizom.org/topcrasher/by_build_date/Firefox/18.0a1/28/all
2. Hover over and click on "Load graph data" until you see empty graphs

Comment 1

[Laura Thomson :laura]

Does this happen in Django?

Comment 2

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to Laura Thomson :laura from comment #1)
> Does this happen in Django?

Unfortunately, I can't get that far (at least not in staging and production), due to bug 880087.

Comment 3

[Schalk Neethling [:espressive]]

I have taken a first look at this bug and from what I can see so far, the graphs that are not plotting anything receives no data back from the server so, the graphs works as it should. Now, of course whether the fact that no data is returned is correct, needs further investigation but, before I do that, I have a general question about these graphs.

Do these add value to the user or, are they simply never or, very rarely used? If that is the case, why do we not simply remove these? If we do, we get a small win in performance by having one less JS file to load and parse and we can get rid of some HTML.

Of course, if these do add value for the user and is used, then I need to further investigate the problem. Just thought I would ask before spending time on it. Thanks!

Comment 4

[Laura Thomson :laura]

In terms of user value, only Kairo can answer, sorry

Comment 5

[Robert Kaiser]

Well, as they haven't been working well at any time I can remember, we usually ignore them completely. That said, having actually working per-signature graphs in a decent size (sorry, but those are really tiny) would have really high user value.

Comment 6

[Schalk Neethling [:espressive]]

Do we know that the above should return anything? Perhaps it is just a situation of there being no data and we need to instead of an empty graph, show a message to the user? As I mentioned before, for the empty plotted graphs nothing was returned from the back-end. The fact that for some data is returned and the graphs works fine, seems to suggest that there is no data for these other graphs.

It would be nice to be able to prove it though.

Comment 7

[Robert Kaiser]

We know that most signatures should have something available there - but as I said before, it always has been ill-working and I don't think the current tiny and only-sometimes-working design is good overall. We need graphs that are probably larger and reliably get decent data.

Comment 8

[Schalk Neethling [:espressive]]

rhelmer, I was thinking about this graph issue and was wondering, the problem you referred to in our email thread (https://bugzilla.mozilla.org/show_bug.cgi?id=934960), could it be causing the problem that is referred to in this bug?

Comment 9

[Robert Helmer [:rhelmer]]

(In reply to Schalk Neethling [:espressive] from comment #8)
> rhelmer, I was thinking about this graph issue and was wondering, the
> problem you referred to in our email thread
> (https://bugzilla.mozilla.org/show_bug.cgi?id=934960), could it be causing
> the problem that is referred to in this bug?

Looks unrelated - at least on stage I see results for the signature_history service.

Comment 10

[Schalk Neethling [:espressive]]

(In reply to Robert Helmer [:rhelmer] from comment #9)
> Looks unrelated - at least on stage I see results for the signature_history
> service.

Hey Rob,

So from IRC using the following page:

Page: topcrasher/products/Firefox/versions/28.0a1

This signature has no data:

memmove | LocalBaseRegQueryValue [http://127.0.0.1:8000/report/list?product=Firefox&range_value=7&range_unit=days&date=2013-11-10&signature=memmove+%7C+LocalBaseRegQueryValue&version=Firefox%3A28.0a1]

And this one does:

EnterBaseline [http://127.0.0.1:8000/report/list?product=Firefox&range_value=7&range_unit=days&date=2013-11-10&signature=EnterBaseline&version=Firefox%3A28.0a1]

Comment 11

[Robert Helmer [:rhelmer]]

(In reply to Schalk Neethling [:espressive] from comment #10)
> (In reply to Robert Helmer [:rhelmer] from comment #9)
> > Looks unrelated - at least on stage I see results for the signature_history
> > service.
> 
> Hey Rob,
> 
> So from IRC using the following page:
> 
> Page: topcrasher/products/Firefox/versions/28.0a1
> 
> This signature has no data:
> 
> memmove | LocalBaseRegQueryValue
> [http://127.0.0.1:8000/report/
> list?product=Firefox&range_value=7&range_unit=days&date=2013-11-
> 10&signature=memmove+%7C+LocalBaseRegQueryValue&version=Firefox%3A28.0a1]
> 
> And this one does:
> 
> EnterBaseline
> [http://127.0.0.1:8000/report/
> list?product=Firefox&range_value=7&range_unit=days&date=2013-11-
> 10&signature=EnterBaseline&version=Firefox%3A28.0a1]

If I use crash-stats-dev.allizom.org (should be the same data source) instead of 127.0.0.1, I see graphs in the graphs tab for both of these.

On https://crash-stats-dev.allizom.org/topcrasher/products/Firefox/versions/28.0a1/date_range_type/build/crash_type/browser/os_name/None?days=7 I see that the "on demand" graph for signature "memmove | LocalBaseRegQueryValue" is blank though.

Comment 12

[Robert Helmer [:rhelmer]]

OK so I have boiled it down to the middleware response 

/crashes/signature_history/product/Firefox/version/28.0a1/signature/memmove | LocalBaseRegQueryValue

{"hits": [], "total": 0

/crashes/signature_history/product/Firefox/version/28.0a1/signature/EnterBaseline

{"hits": [{"date": "2013-11-09", "count": 104, "percent_of_total": 7.2272411396803298}, {"date": "2013-11-08", "count": 308, "percent_of_total": 21.403752605976401}, {"date": "2013-11-07", "count": 1027, "percent_of_total": 71.369006254343304}], "total": 3}

Comment 13

[Schalk Neethling [:espressive]]

(In reply to Robert Helmer [:rhelmer] from comment #12)
> OK so I have boiled it down to the middleware response 
> 
> /crashes/signature_history/product/Firefox/version/28.0a1/signature/memmove
> | LocalBaseRegQueryValue
> 
> {"hits": [], "total": 0
> 
> /crashes/signature_history/product/Firefox/version/28.0a1/signature/
> EnterBaseline
> 
> {"hits": [{"date": "2013-11-09", "count": 104, "percent_of_total":
> 7.2272411396803298}, {"date": "2013-11-08", "count": 308,
> "percent_of_total": 21.403752605976401}, {"date": "2013-11-07", "count":
> 1027, "percent_of_total": 71.369006254343304}], "total": 3}

Yep, I also saw those. So do you agree that it seems like there simply is no data or, do you think one needs to dig deeper and see whether there is any data in the database for memmove | LocalBaseRegQueryValue ? Thanks for looking into this Rob.

Comment 14

[Robert Helmer [:rhelmer]]

(In reply to Schalk Neethling [:espressive] from comment #13)
> (In reply to Robert Helmer [:rhelmer] from comment #12)
> > OK so I have boiled it down to the middleware response 
> > 
> > /crashes/signature_history/product/Firefox/version/28.0a1/signature/memmove
> > | LocalBaseRegQueryValue
> > 
> > {"hits": [], "total": 0
> > 
> > /crashes/signature_history/product/Firefox/version/28.0a1/signature/
> > EnterBaseline
> > 
> > {"hits": [{"date": "2013-11-09", "count": 104, "percent_of_total":
> > 7.2272411396803298}, {"date": "2013-11-08", "count": 308,
> > "percent_of_total": 21.403752605976401}, {"date": "2013-11-07", "count":
> > 1027, "percent_of_total": 71.369006254343304}], "total": 3}
> 
> Yep, I also saw those. So do you agree that it seems like there simply is no
> data or, do you think one needs to dig deeper and see whether there is any
> data in the database for memmove | LocalBaseRegQueryValue ? Thanks for
> looking into this Rob.

I'll dig deeper and see why this is happening.

Comment 15

[Robert Helmer [:rhelmer]]

Hmm OK something is odd here - I think this is the query the mware should be using, I'll have to turn on debug logging for the generated queries to confirm, but this works on dev:

breakpad=> WITH hist AS (
    SELECT
        report_date,
        report_count
    FROM
        tcbs JOIN signatures using (signature_id)
             JOIN product_versions using (product_version_id)
    WHERE
        report_date BETWEEN '2013-11-01' AND '2014-01-01'
        AND product_name = 'Firefox'
        AND version_string = '28.0a1'
        AND signature = 'memmove | LocalBaseRegQueryValue'
    GROUP BY
        report_date, report_count
    ORDER BY 1
),
scaling_window AS (
    SELECT
        hist.*,
        SUM(report_count) over () AS total_crashes
    FROM hist
)
SELECT
    report_date,
    report_count,
    report_count / total_crashes::float * 100 AS percent_of_total
FROM scaling_window
ORDER BY report_date DESC;
 report_date | report_count | percent_of_total 
-------------+--------------+------------------
 2013-11-09  |          195 |       3.80859375
 2013-11-08  |          395 |       7.71484375
 2013-11-07  |         1203 |      23.49609375
 2013-11-06  |         2585 |      50.48828125
 2013-11-05  |          742 |       14.4921875
(5 rows)

EnterBaseline also works (as already expected)

Comment 16

[Robert Helmer [:rhelmer]]

Ah! I think I see the problem - when a signature like "memmove | LocalBaseRegQueryValue" is passed into the signature_history service, it looks like that gets truncated to "memmove" when I print the params in socorro/external/postgresql/base.py:query

Adrian, could you take a look?

Comment 17

[Schalk Neethling [:espressive]]

This bug has been split in two parts. This bug related to changes made to the UI for these signature history graphs. For work on the middleware aspect of this bug see https://bugzilla.mozilla.org/show_bug.cgi?id=938533

Comment 18

[Schalk Neethling [:espressive]]

TEST CASE
---------

Loading topcrashers you should now always see the link to show the graph:

1) If there is not data for the graph, I message should be shown to the user indicating this.
2) If there is data, the graph should drawn and the new styling of the graph should be evident.

Clicking on the close button for the graph should close the graph area. Clicking on the graph icon, should make the graph area visible again.

Comment 19

[[github robot]]

Commits pushed to master at https://github.com/mozilla/socorro

https://github.com/mozilla/socorro/commit/cb95c2c81cd4e3aaec874064eed9400726e2b081
Fix Bug 789526, improve UI and provide user message when no data was received for graph

https://github.com/mozilla/socorro/commit/87ff874f6af96484e5c36cbf9e4427ac9b052525
Merge pull request #1674 from ossreleasefeed/bug789526-non-plotted-graphs-on-topcrasher

Bug789526 non plotted graphs on topcrasher

Comment 20

[Schalk Neethling [:espressive]]

TEST CASE
---------

Navigate to top crashers:
1) The graph icon is now always visible.
2) Clicking on the icon will reveal a loader (progress bar type)
3) If there was data for the graph, the graph should load into the new UI
4) If there is no data a message will be shown to the user
5) If an error occurred while loading the graph data, an error message will be displayed to the user as well as the error if possible.

Comment 21

[Matt Brandt [:mbrandt]]

Thank you Espressive for the fantastic test case that covers the negative as well as positive test cases - QA verified on stage per steps in comment 20