Closed Bug 898432 Opened 11 years ago Closed 9 years ago

Table count is wrong

Categories

(Socorro :: Webapp, task)

Product:
Socorro
Component:
Webapp
Type:
task
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX

People

(Reporter: scoobidiver, Unassigned)

References

Details

Attachments

(1 file)

qa - reopened
593.88 KB, image/png
Details
The table count is completely wrong and worse than before bug 891815. See https://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox:25.0a1&signature=gfxContext%3A%3APushClipsToDT%28mozilla%3A%3Agfx%3A%3ADrawTarget*%29 where there are 540 crashes in Reports and 42 crashes in Table.
It seems hard coded and is independent from the signature! There's only one table per Firefox channel.
Severity: normal → critical
(In reply to Scoobidiver from comment #1) > It seems hard coded and is independent from the signature! There's only one > table per Firefox channel. Yes this is right :/ I don't see the signature being passed to this service (or a way to pass it in http://socorro.readthedocs.org/en/latest/middleware.html#id80) I'll take a look at how the old code did it exactly.
Assignee: nobody → rhelmer
Hm so looking at the PHP code, I don't see how this could have worked before the way you are describing :/ Neither the model nor the view seem to do any filtering based on signature etc: https://github.com/mozilla/socorro/blob/a13bb00b582fb4de1a336b773a08c0129e120182/webapp-php/application/models/build.php https://github.com/mozilla/socorro/blob/a13bb00b582fb4de1a336b773a08c0129e120182/webapp-php/application/views/report/do_list.php#L125 Looking at the PHP app I can't seem to make the numbers between Signature Summary and Table add up either although it's really close (1580 vs. 1554): https://crash-stats-php.mozilla.org/report/list?range_value=7&range_unit=days&date=2013-07-30&signature=nsHttpConnection%3A%3A~nsHttpConnection%28%29&version=Firefox%3A25.0a1 Signature Summary on the PHP site also doesn't seem to obey the "Days" setting so it's a little hard to see, but I never see any change in number of crashes in Table for sure. I will go ahead and make it match the PHP code, but AFAICT comment 1 was not the case in the old code. I'll keep digging though.
Hm ok so just looking at the UI I can see that "Days" setting has an effect on the PHP Table tab, while it does not in the Django app. This might be the whole cause, will investigate that angle.
It worked for signatures with less than 250 crashes (displayed in one page) before bug 891815's patch. The difference in count between the summary and the table in PHP was caused by two reference times (0:00AM for the summary and the query time for the table). It's OK that way.
This continues to be a source of confusion to Socorro users. Laura, can this please be assigned to a developer and release?
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #8) > This continues to be a source of confusion to Socorro users. > > Laura, can this please be assigned to a developer and release? If someone else has time that would be great - I have not had much time to work on it. I did take a look at it today however. Reviewing the comments in here, I think there's a difference between how the PHP implementation actually worked and what was expected - getting to at least be like the PHP impl has not been as straightforward as I would like :/
D'oh, I was looking at the wrong middleware service :( sorry I walked through the PHP code and it's actually using 'crashes/frequency' http://socorro.readthedocs.org/en/latest/middleware.html#id22 So, this is not so mysterious after all.
Status: NEW → ASSIGNED
Commits pushed to master at https://github.com/mozilla/socorro https://github.com/mozilla/socorro/commit/3a1186eb0682b0df444e66e6b2b50fa4cc011998 fixes bug 898432 - use proper model for table count https://github.com/mozilla/socorro/commit/d64f4ef4f2d04e33192d45760a51eb69ca4b19e0 Merge pull request #1401 from rhelmer/bug898432-table-count-wrong fixes bug 898432 - use proper model for table count
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target milestone 56 or 57?
Flags: needinfo?(rhelmer)
(In reply to Scoobidiver from comment #13) > Target milestone 56 or 57? I think it's 57 at this point. :lonnen, this landed on master just today, is 57 the right milestone then (while the issues QA found in 56 are dealt with)?
Flags: needinfo?(rhelmer) → needinfo?(chris.lonnen)
Target Milestone: --- → 57
56 is out the door. 57 is correct.
Flags: needinfo?(peterbe)
Flags: needinfo?(chris.lonnen)
Notes for QA - you basically need to add up the numbers in the "Table" and compare against the total at the top of the "Reports" tab /report/list e.g. on https://crash-stats.allizom.org/report/list?product=Firefox&range_value=7&range_unit=days&date=2013-08-28&signature=RtlDeleteCriticalSection+|+PR_DestroyLock+|+nsHttpConnection%3A%3A~nsHttpConnection%28%29&version=Firefox%3A26.0a1 Scoobidiver may have an easier way to verify. Hey, maybe we should have a total count on that "Table" tab :P
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
So, I can say that this is now consistent with what the PHP app did. I don't quite know what the intended behavior is to be quite honest :( I *assume* the counts should add up, maybe scoobidiver can help?
Flags: needinfo?(scoobidiver)
Scoobidiver is unlikely to answer at this point. Is this still an issue?
(In reply to Chris Lonnen :lonnen from comment #19) > Scoobidiver is unlikely to answer at this point. Is this still an issue? Probably, I'll take a look today.
Well, from all I can see the fix might have worked but meanwhile we regressed something and we do not correctly restrict to the currently selected version(s) any more :(
Flags: needinfo?(scoobidiver)
What is there to do on this? I'd like to close it and file new bugs for anything outstanding, even if those bugs are "document what this table is supposed to represent".
Flags: needinfo?(rhelmer)
(In reply to Chris Lonnen :lonnen from comment #22) > What is there to do on this? I'd like to close it and file new bugs for > anything outstanding, even if those bugs are "document what this table is > supposed to represent". The only outstanding thing is comment 21 - I just looked and I see different results for different versions.
Flags: needinfo?(rhelmer)
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #21) > Well, from all I can see the fix might have worked but meanwhile we > regressed something and we do not correctly restrict to the currently > selected version(s) any more :( kairo can you help me reproduce what you are describing? I see different results under the "table" tab for different Firefox versions on crash-stats.
Flags: needinfo?(kairo)
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #25) > (In reply to Robert Helmer [:rhelmer] from comment #24) > > kairo can you help me reproduce what you are describing? I see different > > results under the "table" tab for different Firefox versions on crash-stats. > > I don't. > > Just look at esp. the end of the table in those report/list pages: > https://crash-stats.mozilla.com/report/ > list?product=Firefox&range_value=7&range_unit=days&date=2014-06- > 09&signature=gfxContext%3A%3APushClipsToDT%28mozilla%3A%3Agfx%3A%3ADrawTarget > *%29&version=Firefox%3A32.0a1#tab-table > https://crash-stats.mozilla.com/report/ > list?product=Firefox&range_value=7&range_unit=days&date=2014-06- > 09&signature=gfxContext%3A%3APushClipsToDT%28mozilla%3A%3Agfx%3A%3ADrawTarget > *%29&version=Firefox%3A31.0a2#tab-table > https://crash-stats.mozilla.com/report/ > list?product=Firefox&range_value=7&range_unit=days&date=2014-06- > 09&signature=gfxContext%3A%3APushClipsToDT%28mozilla%3A%3Agfx%3A%3ADrawTarget > *%29&version=Firefox%3A30.0b#tab-table > https://crash-stats.mozilla.com/report/ > list?product=Firefox&range_value=7&range_unit=days&date=2014-06- > 09&signature=gfxContext%3A%3APushClipsToDT%28mozilla%3A%3Agfx%3A%3ADrawTarget > *%29&version=Firefox%3A29.0.1#tab-table > > For me, those all look identical. And FWIW, so do the "Graph" tabs. Hmm ok thanks for the links, let me dig into this a bit.
Sorry this bug fell off my radar - peterbe or adrian, want to take a look and see if the issues described in this bug are still happening ("Table" tab doesn't match other data on /report/list) Has this been or will this be replaced with ES?
Assignee: rhelmer → nobody
Flags: needinfo?(peterbe)
Flags: needinfo?(adrian)
The entire report/list/ will eventually be replaced by the signature report page. This "Table" tab's content specifically can be found in the "Aggregations" tab of signature report, as the "build id" aggregation. For example: https://crash-stats.mozilla.com/signature/?product=Firefox&signature=OOM+|+small#aggregations The data there is coherent because it has the exact same filters (and data source) as the rest of the page.
Flags: needinfo?(adrian)
What is the group's consensus on this, WONTFIX?
Status: REOPENED → RESOLVED
Closed: 11 years ago → 9 years ago
Flags: needinfo?(peterbe)
Resolution: --- → WONTFIX
Bumping to verified wontfix.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: