Hi Ned, it looks your change(https://chromium-review.googlesource.com/c/chromium/src/+/1278156) is the most recent change on run_isolated_script_test.py and it was included in both first failed builds https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win7%20Tests%20%281%29/84707 and https://ci.chromium.org/buildbot/chromium.webkit/WebKit%20Win10/42052.

Could you take a look if it's possible you change could cause these failures?

Fixed in https://chromium-review.googlesource.com/c/chromium/src/+/1281902, TBR'ed Ken & Dirk to green up the tree

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/09dcd00f7f832753594286999666ddb14c796f7a

commit 09dcd00f7f832753594286999666ddb14c796f7a
Author: Ned Nguyen <nednguyen@google.com>
Date: Tue Oct 16 06:01:50 2018

Reland "[testing/scripts] Add base adapter class that enables more code reuse for all isolated script test"

This is a reland of 18e40bdceea9a7a147d99e35cf138c7872d9d229


It also includes the fix to only generate filter file for isolated_script_test if --isolated-script-test-filter flag is passed

This will make the behavior of testing/scripts/run_isolated_script_test.py matches
with what happened before the refactoring in https://chromium-review.googlesource.com/c/chromium/src/+/1278156

The bug happened because when  --isolated-script-test-filter is not passed,
TypUnittestAdapter.generate_test_filter_args() isn't called, which means the _temp_filter_file file
handle is not closed. Hence attempting to remove the file will cause a crash on Windows platform
(removing a file whose file handle opened).

In this fix, we create _temp_filter_file within TypUnittestAdapter.generate_test_filter_args() and
only clean up the file if it was created.

This also fix generate_test_filter_args to generate flags with self._temp_filter_file.name (used to beself._temp_filter_file)

TBR=kbr@chromium.org, dpranke@chromium.org, dtrainor@chromium.org

Bug: 894261,  895586 ,  895601 
Change-Id: I74255ba2bc7598db9df18cff4bff4407c2a927f8
Reviewed-on: https://chromium-review.googlesource.com/c/1281902
Commit-Queue: Ned Nguyen <nednguyen@google.com>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Reviewed-by: Ned Nguyen <nednguyen@google.com>
Cr-Commit-Position: refs/heads/master@{#599880}
[modify] https://crrev.com/09dcd00f7f832753594286999666ddb14c796f7a/chrome/android/monochrome/BUILD.gn
[modify] https://crrev.com/09dcd00f7f832753594286999666ddb14c796f7a/testing/scripts/common.py
[modify] https://crrev.com/09dcd00f7f832753594286999666ddb14c796f7a/testing/scripts/run_chromedriver_tests.py
[modify] https://crrev.com/09dcd00f7f832753594286999666ddb14c796f7a/testing/scripts/run_gpu_integration_test_as_googletest.py
[modify] https://crrev.com/09dcd00f7f832753594286999666ddb14c796f7a/testing/scripts/run_isolated_script_test.py
[modify] https://crrev.com/09dcd00f7f832753594286999666ddb14c796f7a/testing/scripts/run_telemetry_as_googletest.py

The reland + fix is landed. However, the waterfall is purple so I can't verify.

I believe the purple is not related to my CL since it was relanded at 599880 (https://ci.chromium.org/buildbot/chromium.webkit/WebKit%20Win10/42082) and the first purple is 599763 (https://ci.chromium.org/buildbot/chromium.webkit/WebKit%20Win10/42062)

This looks like an incomplete luci migration. You're looking at the buildbot tester, which has started running experimentally. Its triggering builder is currently still running non-experimentally. The result is a path mismatch in the gs bucket.

https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/WebKit%20Win10?limit=200 seems to be pretty happy.

Yes, this builder was flipped to LUCI and I'm in the middle of decomming the Buildbot one. Sorry about the confusion!