(green) https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20Trusty%20%28dbg%29/builds/5264

(red) https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20Trusty%20%28dbg%29/builds/5265
* virtual/outofblink-cors/external/wpt/fetch/api/basic/integrity.html

(red)
https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20Trusty%20%28dbg%29/builds/5266
* external/wpt/fetch/api/basic/integrity.html
* virtual/outofblink-cors/external/wpt/fetch/api/basic/integrity.html

(green)
https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20Trusty%20%28dbg%29/builds/5267

The error log is

==== Expected =========
Harness Error. harness_status.status = 1 , harness_status.message = Failed to fetch
=======================
==== Actual ===========
Harness Error. harness_status.status = 1 , harness_status.message = Failed to execute 'fetch' on 'Window': The integrity attribute is unsupported in no-cors mode.
=======================

Flakiness dashboard
https://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=external%2Fwpt%2Ffetch%2Fapi%2Fbasic%2Fintegrity.html&testType=webkit_layout_tests

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

commit 041560fb2e63b8b0e0a1c9ab56c0c8cee76c71ec
Author: Vitalii Iarko <vitaliii@chromium.org>
Date: Wed Sep 20 10:50:15 2017

Disable {v/o/}external/wpt/fetch/api/basic/integrity.html (flaky).

No-Presubmit: true
No-Tree-Checks: true
No-Try: true
TBR: tyoshino@chromium.org
Bug:  766983 
Change-Id: Ib9a1d47246f04c706bec9fa6898d2bddeff00384
Reviewed-on: https://chromium-review.googlesource.com/674688
Reviewed-by: vitaliii <vitaliii@chromium.org>
Commit-Queue: vitaliii <vitaliii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#503104}
[modify] https://crrev.com/041560fb2e63b8b0e0a1c9ab56c0c8cee76c71ec/third_party/WebKit/LayoutTests/TestExpectations

I am disabling these tests.

tyoshino@, could you redirect please?

I think this will be solved by https://chromium-review.googlesource.com/c/chromium/src/+/674694 ( bug 766975 )

Hmm, my CL doesn't fully resolve the flakiness: it drops the "The integrity attribute is unsupported in no-cors mode" error message, but I can still occasionally get the "Failed to fetch" one (in integrity-sharedworker.html and integrity-worker.html as well).

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

commit 7d97c3a8550e35ce8af356fa6e3e8a0553a61140
Author: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Date: Thu Sep 21 10:44:54 2017

Fetch: Do not check |integrity| in no-cors mode when constructing a Request

Adapt to https://github.com/whatwg/fetch/pull/584, which removed the check
for |integrity|'s value when constructing a Request in no-cors mode.

Per https://github.com/whatwg/fetch/issues/583: "the issue is that it's
pretty common to do <script integrity="hash"> in your document. This creates
a no-cors request by default. If their service worker script passes through
with fetch(evt.request) then they will get a TypeError."

Note that the external tests added in
https://github.com/w3c/web-platform-tests/commit/96adf8a1a0cdeb70280f0a0e1ef840602c0ce8b0
are still flaky.

Bug:  766975 ,  766983 
Change-Id: I1a787ee39ed94db49ba18f8675edc7dc3019ed26
Reviewed-on: https://chromium-review.googlesource.com/674694
Commit-Queue: Raphael Kubo da Costa (rakuco) <raphael.kubo.da.costa@intel.com>
Reviewed-by: Tsuyoshi Horo <horo@chromium.org>
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Cr-Commit-Position: refs/heads/master@{#503412}
[modify] https://crrev.com/7d97c3a8550e35ce8af356fa6e3e8a0553a61140/third_party/WebKit/LayoutTests/http/tests/fetch/script-tests/request.js
[modify] https://crrev.com/7d97c3a8550e35ce8af356fa6e3e8a0553a61140/third_party/WebKit/Source/modules/fetch/Request.cpp

The flakiness remains. The only data I could gather so far is that the more integrity() calls to http(s) URLs, the more likely it is for things to fail, and the failure is caused by blink::FetchManager::Loader::SRIVerifier::DidGetReadable() leading to blink::FetchManager::Loader::Failed(), which then throws a TypeError in the promise rejection. This all happens in a test that was supposed to pass, so we end up with an unhandled promise rejection that causes that flaky error message from the bug report.

OK, my latest theory is that

  var fetchPromise = fetch(url, fetchRequestInit);

can end up being rejected too early when there's an error -- "too early" as in before the code gets to the promise_test() + promise_rejects() part of the function, so we end up with a more general failure about a promise being rejected without a handler. If I replace |fetchPromise| with separate calls to fetch() in each location it's referenced, the flakiness seems to disappear.

I fixed the flakiness in https://github.com/w3c/web-platform-tests/pull/7471, which was imported in https://chromium-review.googlesource.com/c/chromium/src/+/682937