self.fetchTotalsForRange doesn't existing in socorro/services/sighistory/modern.py

RESOLVED FIXED in 2.2

Status

Socorro
General
RESOLVED FIXED
7 years ago
6 years ago

People

(Reporter: peterbe, Assigned: lonnen)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

3.65 KB, patch
rhelmer
: review+
Details | Diff | Splinter Review
(Reporter)

Description

7 years ago
modern.py was made from classic.py. It doesn't really need 'fetchTotalsForRange' internally anymore but it's still referenced.
(Reporter)

Updated

7 years ago
Assignee: nobody → chris.lonnen
(Assignee)

Comment 1

7 years ago
Created attachment 552280 [details] [diff] [review]
Fix the sql

This patch removes the need for the function by rolling things up into one query.
Attachment #552280 - Flags: review?(peterbe)
(Reporter)

Updated

7 years ago
Attachment #552280 - Flags: review?(peterbe) → review-
(Assignee)

Comment 2

7 years ago
Created attachment 552948 [details] [diff] [review]
better

This is a technically superior patch. I rewrote it independently of the first, thinking I had already done this, only to find the original bug as I neared completion.

Dates are converted using the isoformat method instead of str() as per Peter's original review. If this is r+ and I'm not around, feel free to land it for me.
Attachment #552280 - Attachment is obsolete: true
Attachment #552948 - Flags: review?(rhelmer)
Attachment #552948 - Flags: review?(peterbe)
(Assignee)

Updated

7 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → 2.2
Version: 1.0 → 2.2
Hmm I have been testing this on dev, but I notice after I click on 1-2 graphs on the topcrashers report, it stops working (just spins) and I start seeing requests like this in the middleware:

/200911/topcrash/sig/trend/history/p/Firefox/v/6.0(beta)/sig/##empty##/end/2011-08-13+0000/duration/168/steps/60

(Note the "##empty##" sig)

Is this a bug on the frontend? I don't see this problem in prod, just as a data point.
(Assignee)

Comment 4

7 years ago
I tried 30 graphs in a beta build, including the empty sig, and I 2 of them take much longer than the others to finish but do eventually finish instead of timing out.
Comment on attachment 552948 [details] [diff] [review]
better

This code looks fine to me.

I have been letting graphs spin for ~10 minutes which still haven't completed. If I try the URL logged by mware I get an error:

    [rhelmer@khan socorro-trunk]$ curl 'http://localhost:8080/200911/topcrash/sig/trend/history/p/Firefox/v/6.0b4/sig/hang | mozilla::plugins::PPluginInstanceParent::CallNPP_HandleEvent(mozilla::plugins::NPRemoteEvent const&, short*)/end/2011-08-13+0000/duration/168/steps/60'
    Traceback (most recent call last):
      File "/usr/lib/python2.6/site-packages/web.py-0.33-py2.6.egg/web/wsgiserver/__init__.py", line 1170, in communicate
        req.parse_request()
      File "/usr/lib/python2.6/site-packages/web.py-0.33-py2.6.egg/web/wsgiserver/__init__.py", line 307, in parse_request
        self._parse_request()
      File "/usr/lib/python2.6/site-packages/web.py-0.33-py2.6.egg/web/wsgiserver/__init__.py", line 387, in _parse_request
        rp = int(req_protocol[5]), int(req_protocol[7])
    ValueError: invalid literal for int() with base 10: 'i' 

This is because the URL isn't encoded, if I encode it everything is fine. I'll take a quick look at the frontend code.
Attachment #552948 - Flags: review?(rhelmer) → review+
(In reply to Robert Helmer [:rhelmer] from comment #5)
> This is because the URL isn't encoded, if I encode it everything is fine.
> I'll take a quick look at the frontend code.

Nevermind, I withdraw my concern - I checked and the frontend is urlencoding (using PHP rawurlencode) and it's all fine. If you can't repro what I am seeing on dev, I am find going ahead with this and testing on stage - it definitely fixes a known issue, if there are further issues we can reopen or open a new bug.
(In reply to Robert Helmer [:rhelmer] from comment #6)
> seeing on dev, I am find going ahead with this and testing on stage - it

"... fine going ahead with this and testing on stage"
(Assignee)

Comment 8

7 years ago
Yep. I cannot repro. We can deal with the intermittent failures if they arise as a separate issue.

Landed:
trunk: r3438 http://code.google.com/p/socorro/source/detail?r=3438
branch: r3437 http://code.google.com/p/socorro/source/detail?r=3437
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
(Assignee)

Updated

7 years ago
Attachment #552948 - Flags: review?(peterbe)
Component: Socorro → General
Product: Webtools → Socorro
You need to log in before you can comment on or make changes to this bug.