Hrm, I'm not seeing any problems in the few logs that I have.

I forced a full resync with bugzilla and the bug is showing up as a proposed blocker now but I'd still like to figure out why it never showed up in the first place.

Well...the most obvious possibility, if the algorithm properly categorizes it as a proposed blocker when it sees it, is that for some reason the script never considered it until you forced a full resync. How does it pick what bugs to look at? Could there be something wrong in that mechanism?

No, I looked through the database entries and there wasn't even a record for 847644. I think that something went wrong with a sync and 847644 was never even considered.

This is exactly why I need to push code somewhere but the algorithm basically works like:

• Look for anything blocking the tracker that has changed since the last sync
• !Add/Remove/Update as needed, including dependencies

If the bug wasn't added to the db initially, the algorithm will never pick it up because all changed prior to the last sync are filtered out.

Unfortunately, I don't think there is any way to figure this out without better logs - if I can't figure out why it wasn't considered at first, I don't think that I can figure out what's going on here.

I'd like to keep this open, though since I'm willing to bet that it's going to happen again :-/

I started looking through what logs I do have and something jumps out at me from the sync that should have caught 847644:

{{{
[20120813-04:30AM] [bugzilla] [DEBUG] Calling query with: {'status': ['NEW', 'ASSIGNED', 'ON_DEV',
'MODIFIED', 'POST', 'ON_QA ', 'FAILS_QA', 'PASSES_QA', 'REOPENED', 'VERIFIED', 'RELEASE_PENDING'],
'f1': 'blocked', 'f2': 'OP', 'f3': 'blocked', 'f4': 'status_whiteboard', 'f5': 'bug_status',
'j2': 'OR', 'v1': '752654', 'v3': '2012-08-13 08:00 GMT', 'v4': '2012-08-13 08:00 GMT ', 'v5':
'2012-08-13 08:00 GMT', 'query_format': 'advanced', 'o5': 'changedafter', 'o4': 'changedafter',
'o3': 'changedafter', 'o1': 'anywords'}
}}}

No wonder it didn't find anything - that is a malformed query that would never have worked. Now to figure out why the query was mangled ...

Actually, there is nothing majorly wrong with the bz query listed in comment 4. I've added more comments to the code to explain bugzilla API query syntax and how to handle parenthesis in the query for future reference.

I've added better logging to the bug sync algorithm and I have a theory on why these bugs aren't showing up. The bugzilla query is filtered based on modification times for the blocks, whiteboard and depends on fields - I'm not sure there there is a modification date for newly created bugs and thus, they don't appear in the query results.

I'm doing some local testing with a different query that is less selective and takes creation date into account. Pulling in more bugs ends up taking longer but I think that I've found a way to keep it fast enough (at about 1 minute for F18 alpha, beta, final) and another 2 minutes for a missing bug check which I'll disable once this bug has been closed.

As far as I can tell, this has been fixed and there have been no new reports of bugs missing from the list in the last week.

Closing