Description: webaudio/AudioBuffer/huge-buffer.html The first timeout that I saw on the dashboard for iOS was 3/24/2022 at r291794. The first timeout that I saw on the dashboard for Big Sur was 2/15/2022 at r289876 and the first timeout that I saw on the dashboard for Monterey was 3/17/2022 at r291422, but neither appear relevant to causing this issue. This test seems to have been flaky since the start. History: https://results.webkit.org/?suite=layout-tests&test=webaudio%2FAudioBuffer%2Fhuge-buffer.html&platform=ios&platform=mac&limit=50000 Diff: --- /Volumes/Data/worker/ios-simulator-15-release-gpuprocess-tests-wk2/build/layout-test-results/webaudio/AudioBuffer/huge-buffer-expected.txt +++ /Volumes/Data/worker/ios-simulator-15-release-gpuprocess-tests-wk2/build/layout-test-results/webaudio/AudioBuffer/huge-buffer-actual.txt @@ -1,3 +1,5 @@ +FAIL: Timed out waiting for notifyDone to be called + PASS # AUDIT TASK RUNNER STARTED. PASS Executing "huge buffer"
<rdar://problem/92752803>
REPRODUCTION STEPS I can reproduce this on ToT r293782 Command: run-webkit-tests --root 293782 --clobber-old-results --iterations 250 --exit-after-n-crashes-or-timeouts 1 --no-retry-failures --force -f webaudio/AudioBuffer/huge-buffer.html Result: Regressions: Unexpected timeouts (1) webaudio/AudioBuffer/huge-buffer.html [ Timeout ]
I have marked this test as a flaky timeout while this issue is investigated.
Pull request: https://github.com/WebKit/WebKit/pull/507
Test gardening commit r293796 (250270@main): <https://commits.webkit.org/250270@main> Reviewed commits have been landed. Closing PR #507 and removing active labels.
Looks like just a Slow test in Debug, should probably be marked as [Slow] instead of flaky?
I have marked this test as Slow while this issue is investigated.
Pull request: https://github.com/WebKit/WebKit/pull/588
Test gardening commit r294052 (250458@main): <https://commits.webkit.org/250458@main> Reviewed commits have been landed. Closing PR #588 and removing active labels.
Marking the test as Slow has resulted in the tests passing consistently. History: https://results.webkit.org/?suite=layout-tests&test=webaudio%2FAudioBuffer%2Fhuge-buffer.html&platform=ios&platform=mac&limit=50000
Verified with Eric that the test can run slow and marking the test as slow has resolved the issue.