Another example where no results were reported at all, causing failures on CQ without sheriffs being aware about it: http://chromium-try-flakes.appspot.com/all_flake_occurrences?key=ahVzfmNocm9taXVtLXRyeS1mbGFrZXNyUwsSBUZsYWtlIkhvcmcuY2hyb21pdW0uY2hyb21lLmJyb3dzZXIuc3luYy5Cb29rbWFya3NUZXN0I3Rlc3REb3dubG9hZE1vdmVkQm9va21hcmsM.

Hm. I've just realized that "0" is expected since this is the default value. It seems like we just didn't ever update the record with the actual bug number.

I've studied the logs for the flake "org.chromium.chrome.browser.sync.BookmarksTest#testDownloadMovedBookmark" (from the link in #1) and tried to reconstruct what happened (all times are in UTC):
 1. The test was flaky before August 2016 and there are 12 recorded FlakyRuns (all from 2015).
 1. First 3 FlakyRuns are recorded at 2016-08-23 15:22:12, 2016-08-23 22:52:09 and 2016-08-23 23:44:11.
 2. CronJob /cron/update_issue_tracker starts to schedule processing of the Flake every 30 minutes and first processing call happens at 14:53:00.481 UTC.
 3. Many more FlakyRuns are recorded on 2016-08-24. The first 3 runs are at 16:01:15, 15:45:47 and 15:36:09.
 4.  Issue 640728  is created at 2016-08-24 20:23:08 and only 8 flakes are reported on it.
 5. At 2016-08-24 21:38:58, the issue is marked as a duplicate of  issue 640669 , which was already marked as fixed by then (at 21:33:06).

In datastore the Flake properties are:
 - issue_id == 0
 - old_issue_id == 640728
 - count_all == len(occurrences) == 100
 - num_reported_flaky_runs == 23

Several questions arise out of this:
 1. Why didn't processing start on 2016-08-23 when there were already 3 issues?
 2. What caused processing to start at 2016-08-24 14:53:00? First flake on 2016-18-24 was recorded >1 hour later.
 3. Why only 8 flakes were reported on the issue? There were 77 FlakyRuns in the previous 24 hours.
 4. It is clear that issue_id is set to 0 since  issue 640669  was marked as Fixed. But why is old_issue_id set to 640728?
 5. Why is number of reported FlakyRuns equals to 23?

This is all rather confusing and I wonder if it all could be caused by some race conditions. OTH, they should not happen since I've limited max concurrent tasks to 1. Another cause could be datastore eventual consistency, but I'm just guessing in the wild...

IMHO, this should all just be solved in Dremel. Current design is just too complicated.

I've manually set num_reported_flaky_runs = 100 on Flake entity.

Example flakes that were not reported on the bug, see  issue 661434 .

If this is really a Pri-1, find an owner and update the priority.

This is the result of a bulk edit that moved high priority available bugs to a lower priority in an attempt to be more honest with bug filers.