Steps to reproduce: 1. goto advanced search, https://crash-stats.allizom.org/query?advanced=1 2. select Firefox, All versions 3. click "Filter crash reports" - defaults to 1 week of data Expected: Some results are returned Actual: The search times out and a blank page devoid of html is returned. [17:01:16.126] GET https://crash-stats.allizom.org/query/query?product=Firefox&version=ALL%3AALL&range_value=1&range_unit=weeks&date=12%2F12%2F2011+17%3A01%3A11&query_search=signature&query_type=contains&query=&reason=&build_id=&process_type=any&hang_type=any&do_query=1 [undefined 42363ms] I'm having difficulty isolating the trace on arecibo (http://amckay-arecibo.khan.mozilla.org/list/?priority=&status=&read=&start=&period=&end=&query=&domain=crash-stats.allizom.org&uid=&group=) due to noise but I believe these are the 3 tracebacks associated with this error. - [5xx Error] File: application/libraries/CrashReportDump.php; Line: 123; Message: fopen(): SSL: connection timeout - [5xx Error] File: application/views/moz_pagination/nav.php; Line: 10; Message: Trying to get property of non-object - Web_Service 0 while retrieving http://mware.socorro.stage.webapp.sjc1.mozilla.com/bpapi/search/signatures/product/Firefox/in/signature/search_mode/contains/to/2011-12-12+17%3A01%3A11/from/2011-12-05+17%3A01%3A11/report_type/any/report_process/any/result_number/100/ which was HTTP status 500

I thought it was known that a blank search times out with the pgsql backend and we can't do anything about that atm?

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #1) > I thought it was known that a blank search times out with the pgsql backend > and we can't do anything about that atm? Yeah; similiar to (dupe of?) bug 652880, but that's on prod.

I suspect this has more to do with stage being weaker than prod hardware-wise, but Josh is going to take a look at it first thing in the morning in any case.

I may be mistaken but I believe this was working on stage. Could this simply be because we have a large and fresh batch of data in stagedb?

mbrant, Yes, I believe it's because you're running automation the same day I imported a new snapshot. So you're getting a full week rather than just part of a week. On testing, this query is similarly slow in production. Identical, if you account for the difference in processor speeds.

Verified duplicate