Bug 152892 – Modern IDB: storage/indexeddb/dont-wedge.html is flaky

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[Brady Eidson]

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

[Brady Eidson]

Marked flaky in http://trac.webkit.org/changeset/194765

[Brady Eidson]

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.  =/

[Brady Eidson]

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.

[Brady Eidson]

Setting DRT up to run the test 1000 times I can get it to sometimes hang locally.

Exploring.

[Brady Eidson]

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.

[Brady Eidson]

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.

[Brady Eidson]

(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/

[Brady Eidson]

http://trac.webkit.org/changeset/194904