I think that is a red herring I think.
The test is timing out on all the runs I looked at:
https://build.chromium.org/p/chromium.perf/builders/Linux%20Perf/builds/1960
https://build.chromium.org/p/chromium.perf/builders/Android%20Nexus5%20Perf/builds/570
https://build.chromium.org/p/chromium.perf/builders/Android%20Nexus6%20WebView%20Perf/builds/575
https://build.chromium.org/p/chromium.perf/builders/Win%2010%20High-DPI%20Perf/builds/1210
https://build.chromium.org/p/chromium.perf/builders/Win%208%20Perf/builds/1477

It would make sense that the JSON could not be decoded if its timing out though. The file could be empty. I couldn't find that error in the log for this run:
https://chromium-swarm.appspot.com/task?id=39902e3469177410&refresh=10&show_raw=1

What log is that located in?

Did a bisect get kicked off but not linked to this bug?

I'm not sure what happened to the bisect! Will kick another. Here is an example log on linux with the JSON value decoded message:
https://logs.chromium.org/v/?s=chrome%2Fbb%2Fchromium.perf%2FLinux_Perf%2F1964%2F%2B%2Frecipes%2Fsteps%2Fblink_perf.shadow_dom_on_NVIDIA_GPU_on_Linux%2F0%2Fstdout

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14d2e632f80000

📍 Found significant differences after each of 3 commits.
https://pinpoint-dot-chromeperf.appspot.com/job/14d2e632f80000

Revert "Surface synchronization: Propagate ScreenInfo to OOPIFs/BrowserPlugin"
By xiyuan@chromium.org · Thu Oct 26 22:26:38 2017
chromium @ 28c691b74c89ad3baffcc8f8f67803739f145954

Create PendingScript when script loading is started in PrepareScript()
By hiroshige@chromium.org · Thu Oct 26 22:39:56 2017
chromium @ 9d0b896c09461e4c1fcee17856f768d3e66880bf

Add rappor metrics for measuring launching app name of Browser Actions.
By ltian@google.com · Thu Oct 26 22:42:12 2017
chromium @ 4960963e7c323fdf88690697322175348af996f1

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

Sorry about that, I seem to have run a regression bisect when I meant to run a functional one. Sadly, the test passed, which it shouldn't have. Unassigning and trying again.

Actually, the test passed at all runs. Maybe the timeouts are different for pinpoint/perf waterfall? I'm going to try bisecting on benchmark_duration and see if that gives us anything.

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14cea3eaf80000

📍 Couldn't reproduce a difference.
https://pinpoint-dot-chromeperf.appspot.com/job/14cea3eaf80000

Dave, do you think you could help us with bisecting this problem?

Both these bisects are on the same range:
https://pinpoint-dot-chromeperf.appspot.com/job/14d2e632f80000
https://pinpoint-dot-chromeperf.appspot.com/job/14cea3eaf80000

I could have sworn I set the first one to be a functional bisect, but looks like I screwed up and it is a regression bisect. But the test passed on every run, as far as I can tell. So we thought maybe the test is timing out, and ran a bisect on benchmark_duration. But the second bisect seems to have no values at the first revision, and fail at the second revision? Any idea what's going on here or how we could bisect better?

We should bisect on the test runtime.

We did in https://pinpoint-dot-chromeperf.appspot.com/job/14cea3eaf80000, but the test isn't producing values for benchmark_duration. You can click on the data points to see the test logs, any ideas?

The hardtimeout of this benchmark is 360000, whereas the test fails much earlier. So I suspect it hits i/o timeout, which means the test v0-distribution-with-multiple-shadow-roots.html is stuck. 

For now, I would disable this test then assign to whoever created it to keep investigating this bug.

Since this is happening on every bot but two, I think we agree it isn't the bot, it is the test. 

Looking at a few of the bots and the revision ranges ( I only spot checked 3) you could narrow it down to the revision range: 511908-512018

I agree with Randy that standard_isolated_script_merge.py is a red herring.  That file hasn't changed since April and we haven't added anything that should have impact on the main waterfall (that I know of) for the next merge script.  It looks like in the error the merge script is being passed some bad json and that is causing the failure: 
   raise ValueError("No JSON object could be decoded")

That being said, I looked at Mac 10.12 since it was pretty green before blink_perf.shadow_dom started failing on October 26th.  Looking at the first failing build 1173: https://uberchromegw.corp.google.com/i/chromium.perf/builders/Mac%2010.12%20Perf/builds/1173

One CL that jumped out at me was https://chromium-review.googlesource.com/c/chromium/src/+/732811 since it was reviewed by the owner of blink_perf.shadow_dom (hayato@) and falls in this revision range( 512017)

Looks like Ned might be on board with disabling until we can identify the culprit CL.  adding the owner of this benchmark

Re: comment 9

We see the failure in the second bisect but not the first. I think this is because the second one has no story_filter, and therefore runs the entire benchmark.

I agree with the interpretation of the second bisect. It has no values on the first revision and fails on the second revision. But the bisect should continue, not stop, in that scenario. I've filed https://github.com/catapult-project/catapult/issues/4025

kochi@,

I think you might want to fix this, as well as https://bugs.chromium.org/p/chromium/issues/detail?id=512024.

https://github.com/catapult-project/catapult/issues/4025 is fixed, and the fix is deployed. I'm going to re-run the bisection.

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/10471d26f80000

This is still failing: I'm going to go ahead and disable distribution-with-multiple-shadow-roots.html on all platforms and let kochi@ investigate further.

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

commit 6aa1c94a0f262218f2882bb47866e8aae97918ae
Author: Charlie Andrews <charliea@chromium.org>
Date: Tue Nov 14 00:14:48 2017

Disable blink_perf.shadow_dom story that's timing out on all platforms

TBR=kochi@chromium.org, hayato@chromium.org

Bug:  780506 
Change-Id: I0e014e8974011ba1c4c43cb7386e91073267e2f6
Reviewed-on: https://chromium-review.googlesource.com/767156
Reviewed-by: Charlie Andrews <charliea@chromium.org>
Commit-Queue: Charlie Andrews <charliea@chromium.org>
Cr-Commit-Position: refs/heads/master@{#516108}
[modify] https://crrev.com/6aa1c94a0f262218f2882bb47866e8aae97918ae/tools/perf/benchmarks/blink_perf.py

Lowering to Pri-2 now that it's disabled.

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

commit 81620a91d0345934872abd386d999737b6c767ff
Author: Takayoshi Kochi <kochi@chromium.org>
Date: Thu Nov 16 07:34:48 2017

Remove v0-distribution-with-multiple-shadow-roots Blink perf test.

Multiple shadow roots are removed in M64, and this test doesn't make
sense any more.  Remove the test from Blink's performance tests.

Bug:  780506 ,  512024 
Change-Id: I7847e9e6f081e6c3d6de0186cc8fb02b039d53f3
Reviewed-on: https://chromium-review.googlesource.com/770851
Reviewed-by: Hayato Ito <hayato@chromium.org>
Reviewed-by: Charlie Andrews <charliea@chromium.org>
Commit-Queue: Takayoshi Kochi <kochi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#517016}
[delete] https://crrev.com/f4bfda2512e446f2236ff5c3d75706b0dbdad604/third_party/WebKit/PerformanceTests/ShadowDOM/v0-distribution-with-multiple-shadow-roots.html
[modify] https://crrev.com/81620a91d0345934872abd386d999737b6c767ff/tools/perf/benchmarks/blink_perf.py