Modern IDB: storage/indexeddb/dont-wedge.html is flaky https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=storage/indexeddb/dont-wedge.html
Marked flaky in http://trac.webkit.org/changeset/194765
Trying to explore this now. No matter what I try I can't reproduce locally. I also can't figure out how to get the flakiness dashboard to actually show me the output before it timed out. =/
Got them. For posterity: FAIL: Timed out waiting for notifyDone to be called Check that a page reloaded during an in-flight upgradeneeded event doesn't hang. On success, you will see a series of "PASS" messages, followed by "TEST COMPLETE". indexedDB = self.indexedDB || self.webkitIndexedDB || self.mozIndexedDB || self.msIndexedDB || self.OIndexedDB; dbname = "dont-wedge.html" dbname1 = dbname + '1' dbname2 = dbname + '2' 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.
Setting DRT up to run the test 1000 times I can get it to sometimes hang locally. Exploring.
When the IDBOpenDBRequest is told about its database connection opening in IDBOpenDBRequest::requestCompleted, its context has already stopped, so it doesn't actually create the database connection and/or deliver the event. Also, since the connection never fully opens, it doesn't get closed with the page navigates. This is likely a timing race between the page navigation and the server opening a connection requested before the navigation.
Created attachment 268763 [details] Patch v1 Never came up with a way to truly and reliably reproduce other than "tell DRT to run the test 10,000 times in a row and hope it hits" Before this patch, it would always hit by run ~1000 After this patch it doesn't hit at all, and with logging on I can verify the new code fires every once and awhile, doing what it is support to do.
(In reply to comment #6) > > After this patch it doesn't hit at all, and with logging on I can verify the > new code fires every once and awhile, doing what it is support to do. s/support/supposed/
http://trac.webkit.org/changeset/194904