All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=705380

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgrKe7qQsM


Bot(s) for this bug's original alert(s):

chromium-rel-win7-gpu-intel

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8983989581118515216

=== BISECT JOB RESULTS ===
Bisect failed for unknown reasons

Please contact the team (see below) and report the error.


Bisect Details
  Configuration: winx64intel_perf_bisect
  Benchmark    : page_cycler_v2.typical_25
  Metric       : timeToFirstMeaningfulPaint_avg/pcv1-warm/http___www.html5rocks.com_en_


To Run This Test
  src/tools/perf/run_benchmark -v --browser=release_x64 --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=http...www.html5rocks.com.en. page_cycler_v2.typical_25

Debug Info
  https://chromeperf.appspot.com/buildbucket_job_status/8983989581118515216

Is this bisect wrong?
  https://chromeperf.appspot.com/bad_bisect?try_job_id=6471900286418944


| O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq
|  X  | for more information addressing perf regression bugs. For feedback,
| / \ | file a bug with component Speed>Bisection.  Thank you!

LogDog says:
Bisect cannot identify a culprit: Bisect failed to reproduce the regression with enough confidence.

So, it's curious that the report at #c3 is "Bisect failed for unknown reasons".

Set Speed>Bosection for the #c4

So downloading and running the bisect_report against the posted data gives the correct report.

Digging through the logs, I see that the call to /post_bisect_results was received at:
03:58:08 on instance 00c61b117cd82e40785aa8b3685daa5ecbbfaee2dc0a3f26ffd8fab93db5418f8e8e6af9bdf22ac7

While /update_bug_results was called at:
03:58:00 on instance 00c61b117ca99ba70a7b77660bfb592b04074dd75a665e8cdab428f33cf748f9e02d53f50b6bc66a


But /update_bug_with_results took over a minute to complete, and starts by querying for every tryjob it needs to check. Think what might have happened is that loaded and got the old data, /post_bisect_results was called shortly after and updated it but /update_bug_with_results never saw the updated values. Eventually /update_bug_with_results called job.CheckFailureFromBuildBucket() which sees the buildbucket failure, fiddles with some internal values, then put()'s itself back into ndb (overwriting the valid values from /post_bisect_result) and then updates the bug with the wrong output.

Making the bisect recipe not mark these as failures would help in this case, since it was indeed able to run properly, just not reproduce a regression.

was a temporary spike (noise)