Bug 198435 – Layout test landed flaky in 245873 [ Release ] http/wpt/service-workers/service-worker-networkprocess-crash.html is a flaky failure

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Shawn Roberts]

The following layout test is flaky on Mac WK2 and iOS Simulator Release builds

http/wpt/service-workers/service-worker-networkprocess-crash.html

Probable cause:

New test added in r245873 is a flaky failure on Release builds. 

When run in Debug will get a flaky assertion, or cause other tests to assert. see https://bugs.webkit.org/show_bug.cgi?id=198434

run-webkit-tests http/wpt/service-workers/service-worker-networkprocess-crash.html --iter 100 -f --exit-after-n-failures=2

Flakiness Dashboard:

https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=http%2Fwpt%2Fservice-workers%2Fservice-worker-networkprocess-crash.html

Diff:

--- /Volumes/Data/slave/ios-simulator-12-release-tests-wk2/build/layout-test-results/http/wpt/service-workers/service-worker-networkprocess-crash-expected.txt
+++ /Volumes/Data/slave/ios-simulator-12-release-tests-wk2/build/layout-test-results/http/wpt/service-workers/service-worker-networkprocess-crash-actual.txt
@@ -1,5 +1,6 @@
+
 
 PASS Setup worker 
 PASS Frame being controlled 
-PASS Frame being controlled after network process crash 
+FAIL Frame being controlled after network process crash assert_not_equals: got disallowed value null

[Radar WebKit Bug Importer]

<rdar://problem/51314295>

[youenn fablet]

Created attachment 371098 [details]
Patch

[youenn fablet]

ping review

[Geoffrey Garen]

r=me

> LayoutTests/http/wpt/service-workers/service-worker-networkprocess-crash.html:59
> +    let count = 0;
> +    while (count++ < 20) {
> +        const frame = await withFrame(scope + "/empty.html");
> +        if (frame.contentWindow.navigator.serviceWorker.controller)
> +            break;
> +        frame.remove();
> +        await new Promise(resolve => setTimeout(resolve, 50));
> +    }
> +    assert_true(count < 20);

Seems like it would be nicer to load the frame only once and then check repeatedly that it eventually gets a service worker. The way this test is written, the frame might never get a service worker, and the test wouldn't notice.

[WebKit Commit Bot]

Comment on attachment 371098 [details]
Patch

Clearing flags on attachment: 371098

Committed r246089: <https://trac.webkit.org/changeset/246089>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[youenn fablet]

> Seems like it would be nicer to load the frame only once and then check
> repeatedly that it eventually gets a service worker. The way this test is
> written, the frame might never get a service worker, and the test wouldn't
> notice.

There is an inherent race condition between terminating the network process in UIProcess and detecting network process crash on web process based on IPC connection being closed.
The flakiness here is due to the fact that webprocess checks for a matching registration, then is informed the network process crashes and continues the load as if there is no service worker.
We could probably try to make it work in the future.

[youenn fablet]

Dashboard still shows some flakiness.

[youenn fablet]

(In reply to youenn fablet from comment #8)
> Dashboard still shows some flakiness.

Network process maybe be crashing before the SW SQL database is written on disk.
On restart, there is no service worker.
I'll fix it.

[youenn fablet]

(In reply to youenn fablet from comment #9)
> (In reply to youenn fablet from comment #8)
> > Dashboard still shows some flakiness.
> 
> Network process maybe be crashing before the SW SQL database is written on
> disk.
> On restart, there is no service worker.
> I'll fix it.

Filed bug 198584