See https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_swarming_rel/builds/87250 for instance. (That helped contribute to a CL getting through the CQ that broke base_unittests)

Likely something to do in the logic where test_runner hands off test results to the recipe.

From hangouts:

1) test runner always writing the JSON, even if it has no results: https://codesearch.chromium.org/chromium/src/build/android/test_runner.py?rcl=0&l=744
2) the swarming test recipe code using that to determine what has failed: https://codesearch.chromium.org/chromium/build/scripts/slave/recipe_modules/chromium_tests/steps.py?rcl=0&l=916
3) test_utils.run_tests_with_patch collecting those failures: https://codesearch.chromium.org/chromium/build/scripts/slave/recipe_modules/test_utils/api.py?rcl=0&l=125
4) chromium_tests using that collected list of results to determine whether or not something actually failed: https://codesearch.chromium.org/chromium/build/scripts/slave/recipe_modules/chromium_tests/api.py?rcl=0&l=743
4.2) alternatively, if it's running the deapply logic -- which i'm not sure about but can look up -- determine_new_failures sees an empty list of tests here and thinks there are no new failures https://codesearch.chromium.org/chromium/build/scripts/slave/recipe_modules/test_utils/api.py?rcl=0&l=151
fixes could include (1) having the test runner produce a JSON w/ a dummy failure in the event that an exception causes early termination
(2) having the recipe logic treat an empty JSON as an inherent error