Created attachment 474365 [details] Testcase to reproduce transaction commit on worker termination # Summary When a worker thread running an indexedDB transaction is terminated, WebKit can *commit* the half-complete transaction rather than aborting. This makes transactions, well, non-transactional, which can cause severe data corruption. # Background We are building full offline support into the [Fastmail](https://www.fastmail.com/) web app. Our iOS app is essentially a WKWebView-based wrapper around the same. Data is stored in indexedDB, which runs inside a web worker (shared worker for web browsers, normal worker for our app where we know there can only ever be one UI instance). If interested/relevant, more details of the architecture can be found in [this blog post](https://www.fastmail.com/blog/offline-architecture/). We have noticed some iOS beta testers getting corrupt databases. Inspecting the data we found it was consistent with a transaction having been abandoned half-way through, but the data written up to that point being committed. To test this theory we added a patch so that for every transaction: 1. We insert a sentinel record into the DB 2. We do the operations in the transaction 3. We remove the sentinel record from the DB 4. We commit the transaction This should mean the sentinel record is never committed to the DB. We then added a check before (1) for the sentinel record. If it was present, we knew a transaction had been abandoned but committed. Sure enough, we started getting occasional hits, solely from WebKit. Looking at the logs, it seemed to coincide with the page being reloaded. It looks like the worker is being terminated while in the middle of a transaction, but rather than aborting the transaction as it should it's *committing* what's been written so far. I have managed to produce a test case that shows this behaviour. Note, in this test case I am explicitly terminating the worker, which makes it very reproducible, but we were seeing this sporadically even when not doing so — I presume because the OS was terminating the worker on page reload, perhaps with some short timeout. Not too, if you *remove* the `worker.terminate()` from the test case you see another bug: on the page after reload we can never establish a successful connection to the DB. All requests to it hang. # Steps to reproduce 1. Open https://testcases.fastmail.io/webkit-commit/idb-bug.html 2. Click "Run test" 3. Expected result: "Passed". Actual result: "Failed". I've also attached the testcase; the files are the same. # Request for advice on workaround Obviously we would like to see this fixed, however given the release cycle of iOS we don't want to have to wait for this fix to be present before releasing our offline support. So far we are struggling to find a 100% reliable way of avoiding the bug, as the OS can terminate the worker and cause the issue. I'm hoping that someone with understanding of the WebKit code and the root cause of this might be able to suggest some way we can avoid this issue in the meantime. Thanks for any help!