225670 2021-05-11 12:02:16 -0700 [ BigSur ] webaudio/AudioContext/audiocontext-close-basic.html (layout-test) is a flaky timeout 2021-05-13 10:52:46 -0700 1 1 1 Unclassified WebKit Web Audio WebKit Nightly Build Unspecified Unspecified NEW InRadar P2 Normal --- 1 jenner webkit-unassigned ap cdumez webkit-bot-watchers-bugzilla webkit-bug-importer oldest_to_newest 1759017 0 jenner 2021-05-11 12:02:16 -0700 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. 1759072 1 jenner 2021-05-11 14:58:20 -0700 Flaky timeouts first started to occur at r276186. Before that the test was passing consistently. Working on reproduction steps. 1759073 2 webkit-bug-importer 2021-05-11 14:58:59 -0700 <rdar://problem/77866215> 1759099 3 ap 2021-05-11 16:33:09 -0700 Given this text, it was presumably the first test in a shard. Not that it's a reason for timing out. 1759279 4 cdumez 2021-05-12 09:59:40 -0700 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. 1759287 5 cdumez 2021-05-12 10:18:14 -0700 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. 1759432 6 jenner 2021-05-12 16:02:48 -0700 Updated test expectations to [ Slow ] to see if flaky timeouts stop here: https://trac.webkit.org/changeset/277403/webkit 1759732 7 cdumez 2021-05-13 10:34:10 -0700 (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. 1759741 8 jenner 2021-05-13 10:52:46 -0700 (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.