Bug 196445 – [ Mac Debug ] REGRESSION (r242975) Layout Test storage/indexeddb/modern/deletedatabase-2-private.html is a flaky failure

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Shawn Roberts]

The following layout test is flaky on Mac WK2 Debug

storage/indexeddb/modern/deletedatabase-2-private.html

Probable cause:

After changes made in https://trac.webkit.org/changeset/242975/webkit 

Test started to become a flaky failure on Mac Debug builds. It has shown up once on the iOS Simulator Release queue, and I could reproduce it locally, but only about 1 in 1000 iterations.

With Mac Debug it is failing on average 10 in 500 iterations, and I cannot get it to fail in r242974 or older.

Reproduced with:

run-webkit-tests storage/indexeddb/modern/deletedatabase-2-private.html --iterations 500 -f --debug

Flakiness Dashboard:

https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=storage%2Findexeddb%2Fmodern%2Fdeletedatabase-2-private.html

Diff:

--- /Volumes/Data/slave/mojave-debug-tests-wk2/build/layout-test-results/storage/indexeddb/modern/deletedatabase-2-private-expected.txt
+++ /Volumes/Data/slave/mojave-debug-tests-wk2/build/layout-test-results/storage/indexeddb/modern/deletedatabase-2-private-actual.txt
@@ -11,9 +11,9 @@
 Requesting deleteDatabase
 First connection received versionchange event: oldVersion 1, newVersion null
 First version change complete
-Open request error: AbortError
 Delete database success: oldVersion 1, newVersion null
 Recreating database to make sure it's new and empty
+Open request error: AbortError
 Second upgrade old version - 0 new version - 1
 Unable to get object store in second upgrade transaction (which is correct because it should not be there)
 Second database upgrade success

[Radar WebKit Bug Importer]

<rdar://problem/49483061>

[Shawn Roberts]

Marked flaky in https://trac.webkit.org/changeset/243696/webkit while waiting for a fix.

[Shawn Roberts]

When marking test as flaky in r243696 I did so on iOS, not on Mac.

Updated expectations properly in https://trac.webkit.org/changeset/245315/webkit

[youenn fablet]

I debugged a bit.
From IPC we receive first from NetworkProcess to WebProcess:
1. A notification that a transaction is committed
2. A notification that a database is deleted
The order is always the same.

The first IPC message triggers synchronously the enqueuing of a complete event in IDBTransaction::fireOnComplete.
The second IPC message triggers synchronously the enqueuing of a success event in IDBOpenDBRequest::onDeleteDatabaseSuccess.

After the complete event is fired, a third event (an error event) is enqueued in IDBTransaction::dispatchEvent.

There is a race condition between the second event and the third event.
For this race to be visible, there is a need for the second IPC message to happen quickly enough after the first one so that the first event is not yet dispatched.

I guess that this is more the case with private browsing mode where deleting the database is in memory so very quick and does not require hopping to background threads.
This also explains why this flakiness happens more on debug mode where the enqueueing might be slower.


It is not clear to me whether the spec mandates the order.
I guess we could rewrite the test to unflake it.

[youenn fablet]

Some other observations:
- I failed running the test on Chrome (timeout) and Firefox (failing assertions)
- https://w3c.github.io/IndexedDB/#commit-a-transaction mentions enqueuing a task to fire a complete event. There is no description of enqueuing a request error/success event just after dispatching a complete event.

[youenn fablet]

Created attachment 371601 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 371601 [details]
Patch

Clearing flags on attachment: 371601

Committed r246227: <https://trac.webkit.org/changeset/246227>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.