[w3c/IndexedDB] Steps for committing a transaction don't prevent the cleanup steps from allowing subsequent requests (Issue #489)

Zaggy1024 created an issue (w3c/IndexedDB#489)

I'm working on handling requests serially in [Ladybird](https://github.com/LadybirdBrowser/ladybird/), since we've had some event ordering issues. In the process, I've come up with a few test cases that are seemingly covered by the spec.

However, I ran into one issue that I can't find an answer for in the spec. Given the following code:

```js
const setupReq = indexedDB.open("commit-prevents-requests", 1);
const storeName = "store";
setupReq.onupgradeneeded = (e) => {
    e.target.result.createObjectStore(storeName);
};
setupReq.onsuccess = (e) => {
    const db = e.target.result;

    const transaction = db.transaction(storeName, "readwrite");
    const store = transaction.objectStore(storeName);

    const firstPut = store.put("foo", "bar");

    transaction.commit();

    firstPut.onsuccess = () => {
        try {
            store.put("lorem", "ipsum");
            console.log("second put did not throw");
        } catch (e) {
            console.log("second put threw " + e.name);
        }
    };
};
```

I believe the intent is for the second `put()` to throw an exception, but given the spec steps, it doesn't seem like it would. Specifically, the steps for [committing a transaction](https://w3c.github.io/IndexedDB/#commit-transaction) set the state to committing, but the [cleanup Indexed Database transactions](https://w3c.github.io/IndexedDB/#cleanup-indexed-database-transactions) steps which run in the microtask checkpoint immediately following the assignment of the `onsuccess` callback resets the state back to inactive. Is there something else that's intended to prevent this? In our implementation, which tries follows the spec very closely, the second put doesn't trigger an exception, but I may have missed something.

For now, the solution I've found in our implementation (with which it passes all web platform tests and my new tests alike) is to clear the cleanup event loop when committing a transaction, to prevent the state being reset.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/489
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/IndexedDB/issues/489@github.com>