Closed Bug 411354 Opened 12 years ago Closed 9 years ago

Add ability to search by build ID

Categories

(Socorro :: General, task, P1)

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: samuel.sidler+old, Assigned: adrian)

References

()

Details

(Whiteboard: [crashkill] [search])

Attachments

(4 files, 2 obsolete files)

Reported by ispiked, Jun 29, 2007

Need to be able to search based on a given build ID. Probably need to
expland this to do ranges of build IDs, not just a single one.

TODO: For some reason this doesn't work in the case where a product is not
selected.

--

Comment 1 by bsmedberg, Jul 03, 2007

(No comment was entered for this change.)

Labels: -Type-Defect Type-Enhancement Milestone-3

--

Comment 2 by morgamic, Nov 02, 2007

Bumping this to M2.  This is important to gain information per build about MTBF -
Mean Time Between Failure.  It gives us insight on whether the build is improving overall or if its getting worse over time.  That trend helps us gauge the robustness of the product.

We are exploring other points of entry for this data, but so far this is the best.

Labels: -Milestone-3 Milestone-2

--

Comment 3 by bsmedberg, Nov 02, 2007

Yeah, this has been brought up as important for the topcrash reports: limiting the query by build-date (buildid) gives much more accurate results.

It's easy enough to add to the search form.

--

Comment 4 by morgamic, Nov 29, 2007

Working on this.
Priority: -- → P2
Status: NEW → ASSIGNED
Target Milestone: --- → 0.6
This is pretty important now that we're about to release an RC2 of Firefox 3. We need a way to tell the difference between RC1 and RC2 on the top crash page, specifically. I can fake it if I can search by build ID though. That'd be more than good enough for now...
Target Milestone: 0.6 → 0.5
Committed support for this in revision 391. Once implemented, we should be able to access the page by visiting http://crash-stats.mozilla.org/topcrasher/byversion/Firefox/3.0/<buildId>.
What's the timeframe for getting this live?
Justin did you back out the aggregate stuff so its on a branch?  If so we can stage this today.
I did back out the aggregate stuff last week. Should be ready to go.
Target Milestone: 0.5 → 0.6
Target Milestone: 0.6 → ---
We need to add this to the top crasher listing as well for test builds.
Assignee: morgamic → aking
Target Milestone: --- → 0.7
From our meeting on Friday this would be a basic text field on the search page where the build could be manually entered.
Duplicate of this bug: 465815
(In reply to comment #7)
> From our meeting on Friday this would be a basic text field on the search page
> where the build could be manually entered.

as a range?  suggested in comment 0 - which would be very helpful 
eg.  >= 20081118
Priority: P2 → P1
Duplicate of this bug: 478817
Is there further roadmap information on making this possible?   

The most recent accounting I find is TBD of https://wiki.mozilla.org/Breakpad/2009Q3RoadMap  It would be useful today of course, but this will become much more important as Thunderbird goes into shorter development cycles - https://wiki.mozilla.org/User:Dmose/Tb_Post-3.0_Scratchpad
No longer blocks: 478817
The lack of this feature makes tracking topcrashes in nightlies (trunk or branch) nearly impossible; it's why I don't even bother, and only look at betas.
Whiteboard: [crashkill]
Target Milestone: 0.7 → 1.4
Patch adds a build_id field to the query form, updates the rules for a "too general" search to allow for either a prod/vers OR a build number, and adds build clause to search SQL.
Attachment #420218 - Flags: review?(ryan)
Target Milestone: 1.4 → 1.3
Comment on attachment 420218 [details] [diff] [review]
First attempt to add search by build to query form

Code looks fine.  r+
Attachment #420218 - Flags: review?(ryan) → review+
warning: build is not an indexed column in the reports partitions.  In order for this to work reasonably in production, each partition will have to get this index.
(In reply to comment #15)
Great catch. I'll run the SQL by you to create the index.
Sending        webapp-php/application/libraries/MY_SearchReportHelper.php
Sending        webapp-php/application/models/common.php
Sending        webapp-php/application/views/common/query_form.php
Sending        webapp-php/css/screen.css
Transmitting file data ....
Committed revision 1675.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Adds index creation to schema.py
Attachment #420355 - Flags: review?(lars)
A series of index creation SQL statements for existing partitions.
Attachment #420356 - Flags: review?(lars)
Attachment #420356 - Flags: review?(griswolf)
Attachment #420355 - Flags: review?(griswolf)
Here are the affected queries, with 2 permutations for analyzing the queries:
http://pastebin.mozilla.org/695130
After some examination of 
  EXPLAIN (one of several queries involving the build table) ;
Decided two indexes are useful: One is new, one is an extension of an old index. 
Also found one redundant index.

Indexes cannot be ALTERED to have new columns, so both the redundant index and the extended one are dropped, then the new and extended ones are built.

Note that the first few partitions are not useful: Two are too small to matter, and the one for 2009-02-02 is both too large, and does not actually contain (only) data with date_processed that it should. Those three partitions are not indexed.
Attachment #420356 - Attachment is obsolete: true
Attachment #420451 - Flags: review?(ozten.bugs)
Attachment #420451 - Flags: review?(lars)
Attachment #420356 - Flags: review?(lars)
Attachment #420356 - Flags: review?(griswolf)
Comment on attachment 420355 [details] [diff] [review]
First stab at Updates to schema.py 

Superseded by changed requirements. New code checked in: r1684
Attachment #420355 - Flags: review?(griswolf) → review-
Comment on attachment 420451 [details]
Drop and create some indexes on existing reports partitions

Sounds good.
Attachment #420451 - Flags: review?(ozten.bugs) → review+
Drat. That should teach me to test a file that hasn't been written to disk, and then upload that file, still in its bad state. Sigh. But it probably won't.
Attachment #420451 - Attachment is obsolete: true
Attachment #420451 - Flags: review?(lars)
buildid from one of my crashes pulled up a fine list. 20091220050304

2010011000 is a tad short?
(In reply to comment #25)
Yes, this is deployed and should be ready.
Is it possible to search with the initial substring of the build ID so we can search for all crashes for a specific day?
(In reply to comment #28)
Yes, reopening and setting to next release.
Target Milestone: 1.3 → 2.0
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Should tackle this modification with the other search bugs
Whiteboard: [crashkill] → [crashkill] [search]
Attachment #420355 - Flags: review?(lars)
Assignee: ozten.bugs → nobody
What is needed to close this: search on buildid prefix.  

Will our planned ES implementation Just Fix This?
Assignee: nobody → adrian
The current implementation of the new search API does search by build id. Searching into a range shouldn't be difficult to add, I just need to know if this build id is an integer, and we would have to change the ES mapping of this field so the range function is possible. 

If the build id is not an integer, the range would not be possible. We could search into the build date though, or use date range. 

This is only using ES, idk how hard it would be to implement that with the Postgres version.
Staying in 2.0, or going to 2.1?  I don't mind if it's not supported in the PG version.
Searching for one build id is ok, searching for ranges should be pushed to 2.1.
Searching by a range of build ids is pushed to 2.1.
Target Milestone: 2.0 → 2.1
Target Milestone: 2.1 → 2.2
Target Milestone: 2.2 → 2.3
Blocks: 677434
First part of this problem is solved (being able to search for one or several build ids). Was part of Socorro 2.0. 

Second part of this bug (search by range of build ids) will be covered by bug 677434.
Status: REOPENED → RESOLVED
Closed: 10 years ago9 years ago
Resolution: --- → FIXED
Flags: in-testsuite?
Flags: in-litmus?
Component: Socorro → General
Product: Webtools → Socorro
You need to log in before you can comment on or make changes to this bug.