REGRESSION (r227340): Layout Test fast/workers/worker-cloneport.html is a flaky failure

[Ryan Haddad]

The following layout test is flaky on macOS Release WK2

fast/workers/worker-cloneport.html

Probable cause:

Unknown.

Flakiness Dashboard:

https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=fast%2Fworkers%2Fworker-cloneport.html

--- /Volumes/Data/slave/highsierra-release-tests-wk2/build/layout-test-results/fast/workers/worker-cloneport-expected.txt
+++ /Volumes/Data/slave/highsierra-release-tests-wk2/build/layout-test-results/fast/workers/worker-cloneport-actual.txt
@@ -1,6 +1,7 @@
 Test MessagePort messaging/entangle/detangle across threads. Should print "SUCCESS" when done.
 
 PASS: Received request for 50000 messages
+FAILURE: Received: 0 events - expected: 50000
 SUCCESS - received 50000 messages.
 DONE

[Ryan Haddad]

This regressed with https://trac.webkit.org/changeset/227340/webkit

I can reproduce the failure with a build of r227340 using the following:

run-webkit-tests fast/workers/worker-cloneport.html -fg --iter 25 --no-retry-failure

I cannot reproduce with r227339.

[Radar WebKit Bug Importer]

<rdar://problem/37005504>

[Brady Eidson]

(In reply to Ryan Haddad from comment #0)
> The following layout test is flaky on macOS Release WK2
> 
> fast/workers/worker-cloneport.html
> 
> Probable cause:
> 
> Unknown.

How sure are we there's no crashes?

[Chris Dumez]

(In reply to Brady Eidson from comment #3)
> (In reply to Ryan Haddad from comment #0)
> > The following layout test is flaky on macOS Release WK2
> > 
> > fast/workers/worker-cloneport.html
> > 
> > Probable cause:
> > 
> > Unknown.
> 
> How sure are we there's no crashes?

https://build.webkit.org/results/Apple%20High%20Sierra%20Release%20WK2%20(Tests)/r227764%20(2595)/results.html shows no crash

[Matt Lewis]

marked as flaky on macOS release:
https://trac.webkit.org/changeset/227865/webkit

[Chris Dumez]

I can easily reproduce the issue with the command provided by Ryan.

[Chris Dumez]

 PASS: Received request for 50000 messages
+FAILURE: Received: 0 events - expected: 50000 // Evidence a timeout timer has fired too early
 SUCCESS - received 50000 messages. // Evidence the test is succeeding.
 DONE

The code looks like:
        // Queue up a task to execute once the messages have been processed. The timeout value is set fairly large to account for Chromium's different message delivery architecture.
        // This only fires in the case of a test failure, so it does not slow down test running.
        var timer = setTimeout(function() {
            log("FAILURE: Received: " + itemNum + " events - expected: " + numMessages);
        }, 1000);

So if we've not received all the messages within one second, that line will be printed out. This is clearly an issue with the test.

[Chris Dumez]

Created attachment 332803 [details]
Patch

[Ryosuke Niwa]

Comment on attachment 332803 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=332803&action=review

> LayoutTests/fast/workers/worker-cloneport.html:60
> -        }, 1000);
> +        }, 20000);

20s? That's more than DRTs timeout. How about 8s?

[Chris Dumez]

Created attachment 332805 [details]
Patch

[Chris Dumez]

(In reply to Ryosuke Niwa from comment #9)
> Comment on attachment 332803 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=332803&action=review
> 
> > LayoutTests/fast/workers/worker-cloneport.html:60
> > -        }, 1000);
> > +        }, 20000);
> 
> 20s? That's more than DRTs timeout. How about 8s?

Deal.

[WebKit Commit Bot]

Comment on attachment 332805 [details]
Patch

Clearing flags on attachment: 332805

Committed r227935: <https://trac.webkit.org/changeset/227935>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.