Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wait loop questions #436

Open
stelar7 opened this issue Jan 1, 2025 · 1 comment
Open

Wait loop questions #436

stelar7 opened this issue Jan 1, 2025 · 1 comment

Comments

@stelar7
Copy link

stelar7 commented Jan 1, 2025

In Upgrading a database step 11 is supposed to wait for the transaction to finish.

A transaction is finished once it enters the finished state (after commit or abort)

Calling indexedDB.open("test", 1) will cause an upgrade, and then step 10.5 could change the state (via autocommit, or user action), but then we instantly set it back to inactive in step 10.6

  • Should step 11 instead be waiting for the task created in step 10 to finish? Or am I missing something here?

Given the following snippet:

let db;
const open_rq = indexedDB.open(undefined, 9);

open_rq.onupgradeneeded = function (e) {
    db = e.target.result;
};
    
open_rq.onsuccess = function (e) {
    db.close();
    let open_rq2 = indexedDB.open(db.name, 10);
};

Once we get to close a database connection step 3. we will be stuck in an infinite loop, because at no point has the transaction gone to the finished state. (The onupgradeneeded callback does nothing that would cause an abort or commit)

  • Is there a spec step im missing that handles this case?
@stelar7 stelar7 changed the title Database upgrade loop question Database upgrade wait loop question Jan 1, 2025
@stelar7 stelar7 changed the title Database upgrade wait loop question Wait loop questions Jan 1, 2025
@inexorabletash
Copy link
Member

During the firing the version change event (10.5), script may make additional requests. These would keep the transaction alive, so going inactive at 10.6 would not cause the transaction to auto-commit. So waiting for the transaction to finish in step 11 is intentional.

In the case where no requests are made (e.g. your code example), the relevant prose is in the transaction lifetime definition: "The implementation must attempt to commit a transaction when all requests placed against the transaction have completed and their returned results handled, no new requests have been placed against the transaction, and the transaction has not been aborted" The intention is that once we reach a state where all existing requests are completed and new requests can be made, the transaction should attempt to commit.

The statement could be made more explicit e.g. by stating "The implementation must attempt to commit a transaction when it is inactive, all requests..."

Making the whole transaction lifecycle more algorithmic would also be nice. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants