TestWebKitAPI.EditorStateTests.TypingAttributesTextAlignmentStartEnd seems flaky on iOS. In https://ews-build.webkit.org/#/builders/9/builds/11291, the test passed in run-api-tests step. However, in the immediately next retry step (re-run-api-tests), it failed.
<rdar://problem/56814640>
I’m unable to reproduce this failure locally (both by using --iterations 100, and by wrapping the test in a loop for 100 iterations and using --no-timeout).
Created attachment 382584 [details] Speculative fix
We had a string of failures awhile back on post-commit testers, https://results.webkit.org/?suite=api-tests&test=TestWebKitAPI.EditorStateTests.TypingAttributesTextAlignmentStartEnd&before_id=251111, but I doubt that's the same bug. My hunch here is that this is a timing problem and that our EWS bots are much faster than our trunk bots.
(In reply to Jonathan Bedard from comment #4) > We had a string of failures awhile back on post-commit testers, > https://results.webkit.org/?suite=api-tests&test=TestWebKitAPI. > EditorStateTests.TypingAttributesTextAlignmentStartEnd&before_id=251111, but > I doubt that's the same bug. > > My hunch here is that this is a timing problem and that our EWS bots are > much faster than our trunk bots. Those failures appear to be due to an unrelated assertion that was presumably caused by r251090 (and later fixed in a rollout in r251106). ~2000 API tests were all failing in tandem during that time.
Comment on attachment 382584 [details] Speculative fix View in context: https://bugs.webkit.org/attachment.cgi?id=382584&action=review > Tools/TestWebKitAPI/EditingTestHarness.mm:197 > + const NSTimeInterval loggingTimeout = 3; I think you should consider not having a timeout here, just depending on the test-wide timeout, to better integrate with e.g. --no-timeout
(In reply to Tim Horton from comment #6) > Comment on attachment 382584 [details] > Speculative fix > > View in context: > https://bugs.webkit.org/attachment.cgi?id=382584&action=review > > > Tools/TestWebKitAPI/EditingTestHarness.mm:197 > > + const NSTimeInterval loggingTimeout = 3; > > I think you should consider not having a timeout here, just depending on the > test-wide timeout, to better integrate with e.g. --no-timeout (We chatted about this over Slack) The timeout here is just for logging, to make sure that something useful gets logged to stdout in the case where the test does timeout. This would still respect any --time-out option specified via the harness.
The commit-queue encountered the following flaky tests while processing attachment 382584 [details]: requestidlecallback/requestidlecallback-document-gc.html bug 203745 (author: rniwa@webkit.org) The commit-queue is continuing to process your patch.
Comment on attachment 382584 [details] Speculative fix Clearing flags on attachment: 382584 Committed r251931: <https://trac.webkit.org/changeset/251931>
All reviewed patches have been landed. Closing bug.