Makes sense; should be a quick change; taking a quick look today.

CL: https://codereview.chromium.org/1782263002

I think this would make it so that you could use return_code bisects to find the point where a test starts passing again.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/tools/build.git/+/af09373a74caef630936194ccf2b69b2e7b7bf3d

commit af09373a74caef630936194ccf2b69b2e7b7bf3d
Author: qyearsley@chromium.org <qyearsley@chromium.org>
Date: Wed Mar 16 21:09:05 2016

Don't check improvement direction for return_code bisects.

BUG= 593865 

Review URL: https://codereview.chromium.org/1782263002

git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/build@299327 0039d316-1c4b-4281-b951-d872f2087c98

[modify] https://crrev.com/af09373a74caef630936194ccf2b69b2e7b7bf3d/scripts/slave/recipe_modules/auto_bisect/bisector.py
[modify] https://crrev.com/af09373a74caef630936194ccf2b69b2e7b7bf3d/scripts/slave/recipe_modules/auto_bisect/bisector_test.py

Should be fixed; not yet verified. Started a test bisect job to verify:
https://chromeperf.appspot.com/buildbucket_job_status/9017928538620488192

=== Auto-CCing suspected CL author sunnyps@chromium.org ===

Hi sunnyps@chromium.org, the bisect results pointed to your CL below as possibly
causing a regression. Please have a look at this info and see whether
your CL be related.


===== BISECT JOB RESULTS =====
Status: completed


===== SUSPECTED CL(s) =====
Subject : gpu: Ensure that preempted channels wake up after preemption.
Author  : sunnyps
Commit description:
  
When a message queue is paused it is either due to preemption or being
descheduled. If it's because of preemption the message queue should post
a task to wake up later. Otherwise it will remain stuck forever and
because of sync token dependencies it's possible that the browser also
gets stuck.

BUG=591192
TEST=manual testing of hw accelerated video and webgl

Review URL: https://codereview.chromium.org/1775763002

Cr-Commit-Position: refs/heads/master@{#379895}
Commit  : f00f494dfc11b277c0b882735d9e1649d5156bea
Date    : Tue Mar 08 20:08:34 2016


===== TESTED REVISIONS =====
Revision                Exit Code   Std. Dev.   Num Values  Good?
chromium@379854         1           N/A         5           good
chromium@379875         1           N/A         5           good
chromium@379885         1           N/A         5           good
chromium@379890         1           N/A         5           good
chromium@379893         1           N/A         5           good
chromium@379894         1           N/A         5           good
chromium@379895         0           N/A         5           bad
chromium@379935         0           N/A         5           bad

Bisect job ran on: android_one_perf_bisect
Bug ID: 593865

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --also-run-disabled-tests smoothness.tough_filters_cases
Test Metric: Filter-queueing_durations/Filter-queueing_durations
Relative Change: 100.00%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_one_perf_bisect/builds/1215
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9017928538620488192


| 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 label Cr-Tests-AutoBisect.  Thank you!

Sorry, sunnyps! This was just a test of the bisect bots, no actual bug for you to fix (actually it's saying you fixed a bug)

Yep, and this has also confirmed that bisect doesn't auto-abort for return code bisects