storage/indexeddb/deletedatabase-delayed-by-open-and-versionchange.html flaky on mac-wk2 Most recent failure: <https://build.webkit.org/results/Apple%20Yosemite%20Release%20WK2%20(Tests)/r197193%20(12346)/results.html> Flakiness dashboard: <https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=storage%2Findexeddb%2Fdeletedatabase-delayed-by-open-and-versionchange.html> --- /Volumes/Data/slave/yosemite-release-tests-wk2/build/layout-test-results/storage/indexeddb/deletedatabase-delayed-by-open-and-versionchange-expected.txt +++ /Volumes/Data/slave/yosemite-release-tests-wk2/build/layout-test-results/storage/indexeddb/deletedatabase-delayed-by-open-and-versionchange-actual.txt @@ -22,7 +22,7 @@ versionChangeComplete = true onOpenSuccess(): -PASS blockedCalled is true +FAIL blockedCalled should be true. Threw exception ReferenceError: Can't find variable: blockedCalled h = event.target.result h.close()
(In reply to comment #0) > onOpenSuccess(): > -PASS blockedCalled is true > +FAIL blockedCalled should be true. Threw exception ReferenceError: Can't > find variable: blockedCalled > h = event.target.result > h.close() That is... just nuts.
Marked this test as flaky in <http://trac.webkit.org/projects/webkit/changeset/197377>
Ahhh. Okay, understood. This is just a timing problem in the test. In WK2, due to IPC variability, it *is* actually possible for the open + versionChange request to complete before the deleteRequest is even serviced, so it never gets blocked. We could change the test to extend the versionChange transaction until *after* blockedCalled is true, which will make it predictable.
Created attachment 274628 [details] Patch v1
http://trac.webkit.org/changeset/198504