Bug 206965

Summary: REGRESSION: (253807) [ macOS iOS ] storage/indexeddb/intversion-long-queue-private.html is flaky failing
Product: WebKit Reporter: Jacob Uphoff <jacob_uphoff>
Component: New BugsAssignee: Sihui Liu <sihui_liu>
Status: RESOLVED FIXED    
Severity: Normal CC: achristensen, alecflett, beidson, commit-queue, ews-watchlist, jsbell, rniwa, sihui_liu, tsavell, webkit-bot-watchers-bugzilla, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Update Test Expectations
none
Patch
none
Patch none

Jacob Uphoff
Reported 2020-01-29 13:59:40 PST
storage/indexeddb/intversion-long-queue-private.html This test is flaky failing I was able to reproduce the failure and found that the failure was introduced in r253807 History: https://results.webkit.org/?suite=layout-tests&suite=layout-tests&test=storage%2Findexeddb%2Fintversion-long-queue-private.html&test=storage%2Fwebsql%2Fstatement-error-callback.html&platform=ios&platform=mac Diff: --- /Volumes/Data/slave/catalina-release-tests-wk2/build/layout-test-results/storage/websql/statement-error-callback-expected.txt +++ /Volumes/Data/slave/catalina-release-tests-wk2/build/layout-test-results/storage/websql/statement-error-callback-actual.txt @@ -1,15 +1,7 @@ CONSOLE MESSAGE: line 64: Web SQL is deprecated. Please use IndexedDB instead. CONSOLE MESSAGE: line 67: Exception in statement error callback -This test confirms that a transaction is immediately rolled back if and only if a statement's error callback throws an exception, returns true, or doesn't return any value. -PASS - the transaction error callback was invoked. -PASS - the transaction error callback was invoked. -PASS - the transaction error callback was invoked. -PASS - the transaction error callback was invoked. -PASS - the transaction error callback was invoked. -PASS - the transaction error callback was invoked. -PASS - the transaction success callback was invoked. -PASS - the transaction success callback was invoked. -PASS - the transaction success callback was invoked. -PASS - the transaction success callback was invoked. -Test Complete +#PID UNRESPONSIVE - WebKitTestRunner (pid 92995) +FAIL: Timed out waiting for notifyDone to be called +#EOF +#EOF
Attachments
Update Test Expectations (2.39 KB, patch)
2020-01-29 14:10 PST, Jacob Uphoff 		no flags
DetailsFormatted DiffDiff
Patch (4.51 KB, patch)
2020-02-04 17:03 PST, Sihui Liu 		no flags
DetailsFormatted DiffDiff
Patch (7.40 KB, patch)
2020-02-05 08:30 PST, Sihui Liu 		no flags
DetailsFormatted DiffDiff
Show Obsolete (2) View All Add attachment proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1 2020-01-29 14:00:22 PST
<rdar://problem/59005652>
Jacob Uphoff
Comment 2 2020-01-29 14:10:44 PST
Created attachment 389184 [details] Update Test Expectations
Truitt Savell
Comment 3 2020-01-29 14:16:17 PST
Comment on attachment 389184 [details] Update Test Expectations Clearing flags on attachment: 389184 Committed r255384: <https://trac.webkit.org/changeset/255384>
Sihui Liu
Comment 4 2020-02-04 17:03:57 PST
Created attachment 389747 [details] Patch
Sihui Liu
Comment 5 2020-02-05 08:30:23 PST
Created attachment 389809 [details] Patch
Ryosuke Niwa
Comment 6 2020-02-06 15:07:01 PST
Comment on attachment 389809 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=389809&action=review > LayoutTests/ChangeLog:9 > + Modify a test to make it less flaky. Based on our current implementation, there is no guarantee that Block event on How about based on spec? Is there supposed to be an ordering guarantee or not?
Sihui Liu
Comment 7 2020-02-07 18:04:11 PST
(In reply to Ryosuke Niwa from comment #6) > Comment on attachment 389809 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=389809&action=review > > > LayoutTests/ChangeLog:9 > > + Modify a test to make it less flaky. Based on our current implementation, there is no guarantee that Block event on > > How about based on spec? Is there supposed to be an ordering guarantee or > not? Specs specify how the ordering would be on one open/delete request. https://w3c.github.io/IndexedDB/#deleting-a-database 6 and 8 specify the ordering 2 for delete request. https://w3c.github.io/IndexedDB/#factory-interface and https://w3c.github.io/IndexedDB/#opening specify ensure part of the ordering 1 for open request(UpgradeNeeded event on openRequest2 -> Complete event on VersionChange -> transaction on connection2 -> Success event on openRequest2). It does not guarantee the ordering of all events on different requests.
Ryosuke Niwa
Comment 8 2020-02-10 13:07:33 PST
Comment on attachment 389809 [details] Patch Sounds good to me.
WebKit Commit Bot
Comment 9 2020-02-10 18:07:30 PST
The commit-queue encountered the following flaky tests while processing attachment 389809 [details]: editing/spelling/spellcheck-async-remove-frame.html bug 158401 (authors: morrita@google.com, rniwa@webkit.org, and tony@chromium.org) The commit-queue is continuing to process your patch.
WebKit Commit Bot
Comment 10 2020-02-10 18:08:11 PST
Comment on attachment 389809 [details] Patch Clearing flags on attachment: 389809 Committed r256235: <https://trac.webkit.org/changeset/256235>
WebKit Commit Bot
Comment 11 2020-02-10 18:08:13 PST
All reviewed patches have been landed. Closing bug.
Sihui Liu
Comment 12 2020-02-11 10:22:45 PST
*** Bug 207465 has been marked as a duplicate of this bug. ***
Ryosuke Niwa
Comment 13 2020-02-11 13:58:40 PST
Nice, the test seems to be no longer flaky.
Note You need to log in before you can comment on or make changes to this bug.