Bug 225670 – [ BigSur ] webaudio/AudioContext/audiocontext-close-basic.html (layout-test) is a flaky timeout

• Status: NEW
• Component: Web Audio

[Robert Jenner]

webaudio/AudioContext/audiocontext-close-basic.html

is a flaky timeout on BigSur. 

HISTORY:
https://results.webkit.org/?suite=layout-tests&test=webaudio%2FAudioContext%2Faudiocontext-close-basic.html

TIMEOUT TEXT:
Wait on notifyDone timed out, process WebKitTestRunner pid = 53481#EOF


STDERR TEXT:
2021-05-11 09:47:39.764 DumpRenderTree[17988:145650319] nil host used in call to allowsSpecificHTTPSCertificateForHost
2021-05-11 09:47:39.764 DumpRenderTree[17988:145650319] nil host used in call to allowsAnyHTTPSCertificateForHost:

The STDERR was from a wk1 Debug run.

[Robert Jenner]

Flaky timeouts first started to occur at r276186. Before that the test was passing consistently. 

Working on reproduction steps.

[Radar WebKit Bug Importer]

<rdar://problem/77866215>

[Alexey Proskuryakov]

Given this text, it was presumably the first test in a shard. Not that it's a reason for timing out.

[Chris Dumez]

I think the test is just slow because it is working with many AudioContexts. If you look at the flakiness dashboard, you can see that the test is sometimes passing with high run times (e.g. 22 seconds) so it is not too surprising if it can reach the 30 seconds timeout.

[Chris Dumez]

Test takes 6-8 seconds to run on my machine (which is powerful). I'll see if we can either make the test or our implementation faster.

[Robert Jenner]

Updated test expectations to [ Slow ] to see if flaky timeouts stop here:
https://trac.webkit.org/changeset/277403/webkit

[Chris Dumez]

(In reply to Robert Jenner from comment #6)
> Updated test expectations to [ Slow ] to see if flaky timeouts stop here:
> https://trac.webkit.org/changeset/277403/webkit

Notice the lack of timeouts since the test was marked slow. We have test runs that take 35-38 seconds on some of the bots.

[Robert Jenner]

(In reply to Chris Dumez from comment #7)
> (In reply to Robert Jenner from comment #6)
> > Updated test expectations to [ Slow ] to see if flaky timeouts stop here:
> > https://trac.webkit.org/changeset/277403/webkit
> 
> Notice the lack of timeouts since the test was marked slow. We have test
> runs that take 35-38 seconds on some of the bots.

Absolutely! I suppose this is a good thing, and means that now this is just a performance issue now? In any case, I'm glad it's not timing out anymore.