RESOLVED FIXED 184058
REGRESSION (r229831?): LayoutTest storage/indexeddb/dont-wedge-private.html is a flaky failure
https://bugs.webkit.org/show_bug.cgi?id=184058
Summary REGRESSION (r229831?): LayoutTest storage/indexeddb/dont-wedge-private.html i...
Ryan Haddad
Reported 2018-03-27 16:25:04 PDT
The following layout test is flaky on iOS and macOS storage/indexeddb/dont-wedge-private.html Probable cause: Unknown, this test became flaky within the last 7 days. Flakiness Dashboard: https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=storage%2Findexeddb%2Fdont-wedge-private.html --- /Volumes/Data/slave/sierra-debug-tests-wk2/build/layout-test-results/storage/indexeddb/dont-wedge-private-expected.txt +++ /Volumes/Data/slave/sierra-debug-tests-wk2/build/layout-test-results/storage/indexeddb/dont-wedge-private-actual.txt @@ -10,7 +10,6 @@ deleteDatabase1(): indexedDB.deleteDatabase(dbname1) -In a multi process implementation this deleteDatabase may be blocked temporarily, so we don't check for either the presence or absence of a blocked event. deleteDatabase2(): indexedDB.deleteDatabase(dbname2) @@ -24,8 +23,9 @@ store1.put(0, 0) openOnSuccess1(): -PASS isAfterReload() is true +FAIL isAfterReload() should be true. Was false. PASS successfullyParsed is true +Some tests failed. TEST COMPLETE
Attachments
Patch (3.95 KB, patch)
2018-05-16 15:55 PDT, Brady Eidson
no flags
Ryan Haddad
Comment 1 2018-03-27 16:33:58 PDT
Based on when this started, this could be more fallout from https://trac.webkit.org/changeset/229831/webkit
Radar WebKit Bug Importer
Comment 2 2018-03-28 15:41:13 PDT
Brady Eidson
Comment 3 2018-05-16 13:56:20 PDT
This test is pretty straight forward, as far as IDB tests go. It's somewhat surprising that it has this failure mode. It is interesting that dont-wedge-private has the problem but not dont-wedge This suggests to me it's an aspect of the in-process, in-memory private store. Perhaps this store is synchronous enough to actually allow the open request to finish before the reload takes place. Though that would be some what surprising... I suppose I can try to verify* * - That will be hard because I have been wholly unable to reproduce locally.
Brady Eidson
Comment 4 2018-05-16 15:49:53 PDT
(In reply to Brady Eidson from comment #3) > This test is pretty straight forward, as far as IDB tests go. > > It's somewhat surprising that it has this failure mode. > > It is interesting that dont-wedge-private has the problem but not dont-wedge > > This suggests to me it's an aspect of the in-process, in-memory private > store. > > Perhaps this store is synchronous enough to actually allow the open request > to finish before the reload takes place. > > Though that would be some what surprising... I suppose I can try to verify* > > * - That will be hard because I have been wholly unable to reproduce locally. I'm going to land a speculative fix to the test that makes the asynchronous database activity take MANY MANY more spins of the runloop, reliably so. That should give the location change a chance to always take place first.
Brady Eidson
Comment 5 2018-05-16 15:55:31 PDT
WebKit Commit Bot
Comment 6 2018-05-16 17:33:39 PDT
Comment on attachment 340534 [details] Patch Clearing flags on attachment: 340534 Committed r231880: <https://trac.webkit.org/changeset/231880>
WebKit Commit Bot
Comment 7 2018-05-16 17:33:41 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.