LayoutTest storage/indexeddb/database-close-private.html is a flaky failure First failure seen a week ago around r201494 <https://build.webkit.org/results/Apple%20Yosemite%20Debug%20WK1%20(Tests)/r201772%20(13568)/results.html> <http://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=storage%2Findexeddb%2Fdatabase-close-private.html> --- /Volumes/Data/slave/yosemite-debug-tests-wk1/build/layout-test-results/storage/indexeddb/database-close-private-expected.txt +++ /Volumes/Data/slave/yosemite-debug-tests-wk1/build/layout-test-results/storage/indexeddb/database-close-private-actual.txt @@ -43,10 +43,8 @@ transaction #2 request successful PASS event.target.result is "value2" -All transactions completed - database deletes should now be unblocked. - delete database unblocked -PASS awaiting_transaction_count is 0 +FAIL awaiting_transaction_count should be 0. Was 1. PASS successfullyParsed is true TEST COMPLETE
The first failure that I see was in r201466. Very likely caused by <http://trac.webkit.org/projects/webkit/changeset/201461>.
The test is probably bogus, will check it out in the A.M.
(In reply to comment #0) > LayoutTest storage/indexeddb/database-close-private.html is a flaky failure > > First failure seen a week ago around r201494 > > <https://build.webkit.org/results/Apple%20Yosemite%20Debug%20WK1%20(Tests)/ > r201772%20(13568)/results.html> > <http://webkit-test-results.webkit.org/dashboards/flakiness_dashboard. > html#showAllRuns=true&tests=storage%2Findexeddb%2Fdatabase-close-private. > html> > > --- > /Volumes/Data/slave/yosemite-debug-tests-wk1/build/layout-test-results/ > storage/indexeddb/database-close-private-expected.txt > +++ > /Volumes/Data/slave/yosemite-debug-tests-wk1/build/layout-test-results/ > storage/indexeddb/database-close-private-actual.txt > @@ -43,10 +43,8 @@ > transaction #2 request successful > PASS event.target.result is "value2" > > -All transactions completed - database deletes should now be unblocked. > - > delete database unblocked > -PASS awaiting_transaction_count is 0 > +FAIL awaiting_transaction_count should be 0. Was 1. > PASS successfullyParsed is true > > TEST COMPLETE This is reallllllly weird. The first transaction request *did* finish, as evidenced by the actual results. So why did the count not get lowered?
(In reply to comment #3) > (In reply to comment #0) > > This is reallllllly weird. > > The first transaction request *did* finish, as evidenced by the actual > results. > > So why did the count not get lowered? Oh, duh - The *requests* succeed, but we don't necessarily get the transaction complete event. Okay. Exploring more.
*** Bug 158644 has been marked as a duplicate of this bug. ***
It's obvious how 201461 affected this, and I have a fix.
I created a modified test case that spins up 100 transactions instead of just 2. It's always the same failure more - only 1 hasn't finished. Then I epihanied: This is because the event for the second transaction completing is queued, and not fired, and *then* the delete operation is unblocked before the queued event fires. It can never happen in the DatabaseProcess because of how the IPC races resolves themselves with the in process thread hopping races. - The delete being unblocked will never come in before the transaction complete event fires. This is truly unique to the InProcessIDBServer, which basically spins the main thread run loop to simulate asynchroncity, but much more reliably triggers a case like this.
I have changes to the test itself to make it much more likely to hit (though still not always) And with that I can work on a fix.
Marked test as flaky on Mac in <http://trac.webkit.org/projects/webkit/changeset/203128>