Closed Bug 629552 Opened 14 years ago Closed 11 years ago

Unable to get crash query results

Categories

(Socorro :: General, task)

Product:
Socorro
Component:
General
Platform:
x86
macOS
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED INVALID

People

(Reporter: smooney, Unassigned)

References

Details

(Whiteboard: [search]) 

I use a tool that one of the developers build to give me a daily breakdown of crashes per platform http://dbaron.org/mozilla/crashes-by-build. This typically works great but today all the queries are returning no results. If you look at the results it will also be preselecting the wrong build in the drop down. It should be showing Beta11pre and shows Beta10. I talked to dbaron and he indicated that something weird is getting inserted into the query string. Did we make any changes?
We can also build this into the crash-stats app.  How does it differ from http://crash-stats.mozilla.com/products/Firefox/builds ?
(In reply to comment #1)
> The links in the tool are broken, e.g.
> http://crash-stats.mozilla.com/query/query?product=Firefox&platform=windows&branch=2.0&date=&range_value=30&range_unit=days&query_search=signature&query_type=exact&query=&build_id=20110127030333http://hg.mozilla.org/mozilla-central/rev/b5314bc1a926&process_type=all&do_query=1
> 
> Should be 
> http://crash-stats.mozilla.com/query/query?product=Firefox&platform=windows&branch=2.0&date=&range_value=30&range_unit=days&query_search=signature&query_type=exact&query=&build_id=20110127030333

That particular error only happened on the January 27 links; I think something has probably changed with the data I use; I'll look into that.

However, there's still a problem with the older links, which I hadn't seen before, so it seems likely to be a Socorro regression.  This seems to be that Socorro seems to be modifying the query to insert a "version == ..." constraint somewhat randomly.

For example, on the January 26 win32 link, which is:
http://crash-stats.mozilla.com/query/query?product=Firefox&platform=windows&branch=2.0&date=&range_value=30&range_unit=days&query_search=signature&query_type=exact&query=&build_id=20110126064706&process_type=all&do_query=1
Socorro says it is giving the results for "Results within 30 days of 01/27/2011 17:20:25, and the product is one of Firefox, and the branch is one of 2.0, and the version is one of Firefox:4.0b10, and the platform is one of Windows for build 20110126064706." and it produces no results.  However, the query URL does not mention 4.0b10 at all; there's no version constraint; Socorro seems to be making that up.  If I then edit the query to make it a query for 4.0b11pre, then I get the results.
(In reply to comment #4)
> That particular error only happened on the January 27 links; I think something
> has probably changed with the data I use; I'll look into that.

Very likely to be fallout from bug 549958.
(In reply to comment #4)
> However, there's still a problem with the older links, which I hadn't seen
> before, so it seems likely to be a Socorro regression.  This seems to be that
> Socorro seems to be modifying the query to insert a "version == ..." constraint
> somewhat randomly.
> 
> For example, on the January 26 win32 link, which is:
> http://crash-stats.mozilla.com/query/query?product=Firefox&platform=windows&branch=2.0&date=&range_value=30&range_unit=days&query_search=signature&query_type=exact&query=&build_id=20110126064706&process_type=all&do_query=1
> Socorro says it is giving the results for "Results within 30 days of 01/27/2011
> 17:20:25, and the product is one of Firefox, and the branch is one of 2.0, and
> the version is one of Firefox:4.0b10, and the platform is one of Windows for
> build 20110126064706." and it produces no results.  However, the query URL does
> not mention 4.0b10 at all; there's no version constraint; Socorro seems to be
> making that up.  If I then edit the query to make it a query for 4.0b11pre,
> then I get the results.

Hmmm when I follow that link I get:

"Results within 30 days of 01/27/2011 17:32:05, and the product is one of Firefox, and the branch is one of 2.0, and the platform is one of Windows for build 20110126064706." and I do see results ("292 Results").

This matches what I get with curl. I wonder if it's a cookie or cache or something, dbaron would you mind trying with a different browser or fresh profile?
(In reply to comment #4)
> That particular error only happened on the January 27 links; I think something
> has probably changed with the data I use; I'll look into that.

I fixed this.

> However, there's still a problem with the older links, which I hadn't seen
> before, so it seems likely to be a Socorro regression.  This seems to be that
> Socorro seems to be modifying the query to insert a "version == ..." constraint
> somewhat randomly.

This problem seems to have gone away in the last few minutes.
(In reply to comment #6)
> Hmmm when I follow that link I get:
> 
> "Results within 30 days of 01/27/2011 17:32:05, and the product is one of
> Firefox, and the branch is one of 2.0, and the platform is one of Windows for
> build 20110126064706." and I do see results ("292 Results").
> 
> This matches what I get with curl. I wonder if it's a cookie or cache or
> something, dbaron would you mind trying with a different browser or fresh
> profile?

As I mentioned in the previous comment (which I submitted through the midair-collision-warning), now I no longer see that problem when I click the link in comment 4.
(In reply to comment #8)
> (In reply to comment #6)
> > Hmmm when I follow that link I get:
> > 
> > "Results within 30 days of 01/27/2011 17:32:05, and the product is one of
> > Firefox, and the branch is one of 2.0, and the platform is one of Windows for
> > build 20110126064706." and I do see results ("292 Results").
> > 
> > This matches what I get with curl. I wonder if it's a cookie or cache or
> > something, dbaron would you mind trying with a different browser or fresh
> > profile?
> 
> As I mentioned in the previous comment (which I submitted through the
> midair-collision-warning), now I no longer see that problem when I click the
> link in comment 4.

Hmm so I wonder if you're seeing cached results on the server-side.. does this happen if you use https links?

We are about to start redirecting all http links to https in bug 629453 so that might resolve this problem indirectly...
(In reply to comment #9)
> Hmm so I wonder if you're seeing cached results on the server-side.. does this
> happen if you use https links?

Actually this does not really make sense, since the URL would change... well, if it happens again (esp. if it's reproducable), please let us know.
(In reply to comment #2)
> We can also build this into the crash-stats app.  How does it differ from
> http://crash-stats.mozilla.com/products/Firefox/builds ?

I think the key differences are:
 * it only lists one branch in the table rather than mixing three of them together; since the point is to compare trends between nightlies on a branch, having different branches mixed together makes it very hard to use
 * it doesn't have a bunch of extra "No builds were found" lines for versions that aren't the current nightly version
 * it doesn't have "No builds were found" lines where it should have actually found builds (e.g., Jan 27 & 28 mozilla-central nightlies, 4.0b11pre... which may well have been broken by the same change that my script was broken by)
This had gone away for a while -- but it came back recently, and I filed bug 647591 on the reoccurrence -- though it's possible maybe I should just have documented it here.
Component: Socorro → General
Product: Webtools → Socorro
Whiteboard: [search]
Depends on: 656297
Marking as invalid, please reopen if I'm wrong.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
Bumping to QA verified due to the passage of time as well as the recent release of the new Django backed crash-stats. If the problem persists please file a new bug.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.