Unresolved Dexie bulkGet about fakeindexeddb HOT 3 CLOSED

Man, I'm jealous of your coworkers if this is the kind of bug reports and pull requests they routinely get from you! Really great stuff here.

I think you're right about the cause of the problem, and that the change you made in your PR is the solution least likely to cause other problems, since it's the most similar to how it works now.

I included this fix in v3.1.2.

from fakeindexeddb.

Thanks for the detailed bug report. I spent a little time playing around with it. Looks like each bulkGet is its own transaction, and each promise resolves when the transaction finishes. But in your test case, somehow the 3rd transaction never resolves.

The only difference I see in Dexie's code is that when no keys are given, it resolves the promise faster, because it doesn't have to wait for the async response from actually getting data. But I don't immediately know why that would be a problem. It still looks like the 1st is resolving, then the 2nd is resolving, and then the 3rd... never. Why would the 2nd resolving faster impact the 3rd? Strange. Gets into some hairy parts of fake-indexeddb, probably. I'll have to come back to this later.

from fakeindexeddb.

Thanks for the quick response. (And big thanks for fakeIndexedDB!)

Spent a little time in the debugger, and I think I see the problem:

• Database.processTransactions finds the next unfinished transaction, starts it, and then adds itself as a "complete" listener to continue the process with any remaining transactions
• If there are no remaining requests in the transaction, FDBTransaction._start immediately marks the transaction finished and dispatches the "complete" event
• Dexie's bulkGet([]) generates an FDBTransaction with no requests. This means the "complete" is dispatched before processTransactions has added its listener, so processTransactions is never run again to get to the remaining transactions.

I think that means the issue is better stated as: if there are ever transactions with no requests, any subsequent transactions may not be processed.

Not sure what the right fix would be. Maybe one of:

• In FDBTransation._start, delay the dispatch(complete) until the next cycle?
• In Database.processTransactions, attach the event listeners before executing next._start?
• In Database.processTransactions, check if executing next._start has left next finished, and if so immediately re-schedule processTransactions?

from fakeindexeddb.