1285548 - Some signatures are missing some linked bugs

Status: RESOLVED DUPLICATE of bug 1336279

(Socorro :: Backend, task)

Description

[Marco Castelluccio [:marco]]

For example, https://crash-stats.mozilla.com/signature/?signature=js%3A%3AGCMarker%3A%3AlazilyMarkChildren#bugzilla is only linking to bug 1259214, but actually also bug 1236359 contains the same signature.

The API (https://crash-stats.mozilla.com/api/Bugs/) obviously gives the same wrong results.

Comment 1

[Peter Bengtsson [:peterbe]]

So I'm starting to dig into how the bugzilla-associations cron job works. I know that I refactored most of the code (primarily for a new framework for running cron jobs and I cleaned up the syntax too) but I didn't write it or architect how it works. 

It basically does a query every hour that looks like this: 
https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&deadlinefrom=&deadlineto=&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2016-07-12&chfieldto=Now&chfield=[Bug+creation]&chfield=resolution&chfield=bug_status&chfield=short_desc&chfield=cf_crash_signature&chfieldvalue=&cmdtype=doit&order=Importance&field0-0-0=noop&type0-0-0=noop&value0-0-0=&columnlist=bug_id,bug_status,resolution,short_desc,cf_crash_signature&ctype=csv

Yeah, it's hard to parse. Note the `chfieldfrom=2016-07-12` (and `chfieldto=Now`). That basically gives us all bugs that have changed that day. It pulls down every bug including its status, resolution, short description and cf_crash_signature field. 

Then it iterates over the bugs with a with a crash signature, and every time there's a signature we have stored in our PostgreSQL it makes a bug ID to signature association. 

For what it's worth, I checked every cf_crash_signature for a day and they ALL follow the pattern of `[@ SIGNATURE]`. The algorithm that extracts signatures out of the cf_crash_signature field looks correct too. 

It's really hard to say exactly what the logic is for why it failed to associate with 1236359. 

The more I think about it, the less convinced I am that we should try to store these associations. It's just a matter of time until they are out of sync. I think a much better approach is to change the signature report to query directly to Bugzilla (with a small server-side cache).

Comment 2

[Marco Castelluccio [:marco]]

(In reply to Peter Bengtsson [:peterbe] from comment #1)
> For what it's worth, I checked every cf_crash_signature for a day and they
> ALL follow the pattern of `[@ SIGNATURE]`. The algorithm that extracts
> signatures out of the cf_crash_signature field looks correct too. 

They're often, but not always, following that pattern. See also bug 1285998.

Comment 3

[Peter Bengtsson [:peterbe]]

Oh! I've sort of figured it out. 
This is the query we use to pull down a bunch of bugs:
https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&deadlinefrom=&deadlineto=&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2016-04-04&chfieldto=2016-04-05&chfield=[Bug+creation]&chfield=resolution&chfield=bug_status&chfield=short_desc&chfield=cf_crash_signature&chfieldvalue=&cmdtype=doit&order=Importance&field0-0-0=noop&type0-0-0=noop&value0-0-0=&columnlist=bug_id,bug_status,resolution,short_desc,cf_crash_signature&ctype=csv
Except here I've messed with the `chfieldfrom=2016-04-04&chfieldto=2016-04-05`. Why that particular date? Because that's the date 1236359 was lasted changed on that day. (Scroll to the bottom of https://bugzilla.mozilla.org/show_activity.cgi?id=1236359)

I also tried a day before and day after.

So for some reason, that bug simply isn't findable. Why, I don't know. The bug is not confidential. It was, but it's not any more.

Comment 4

[Peter Bengtsson [:peterbe]]

Oh. Scratch that theory. It's not by change date, it's by creation date. It does turn up on 
https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&deadlinefrom=&deadlineto=&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=2016-01-02&chfieldto=2016-01-03&chfield=[Bug+creation]&chfield=resolution&chfield=bug_status&chfield=short_desc&chfield=cf_crash_signature&chfieldvalue=&cmdtype=doit&order=Importance&field0-0-0=noop&type0-0-0=noop&value0-0-0=&columnlist=bug_id,bug_status,resolution,short_desc,cf_crash_signature&ctype=csv

Comment 5

[Peter Bengtsson [:peterbe]]

So if I run the cron job faked to 2016-01-03 it does indeed pick up that bug (and associates it with the signature). 
But that's today. The cron job where this was supposed to have been picked up was on the 2016-01-04 and according to the history of that bug, that bug was put in the "core-security" group and maybe that's why it didn't get included that day.

Comment 6

[Peter Bengtsson [:peterbe]]

Yeah, that makes sense. The bug was hidden due to being a security bug. Later it was re-opened but at that point the cron job had stopped searching in that window of time. 

To resolve this bug, I really think we need to stop doing this complicated offline permanent storage of associations and instead do a near real-time query to the Bugzilla REST API.

Comment 7

[Will Kahn-Greene [:willkg] ET needinfo? me]

I'm going to remove the "depends" and dupe this to bug #1336279. This is just another case of that.