localForage: Uncaught error in dropInstance onblocked handler

If I try to call dropInstance from one tab while the instance is in use by another tab, the onblocked event is triggered.

                    req.onerror = req.onblocked = function (e) {
                        var db = req.result;
                        if (db) {
                            db.close();
                        }
                        reject(e);
                    };

The handler attempts to close the database before the promise rejects, however the attempt to access request.result throws an error Uncaught DOMException: Failed to read the 'result' property from 'IDBRequest': The request has not finished. at IDBOpenDBRequest.req.onerror.req.onblocked.

It seems either the attempt to close the database should not happen here (if blocked implies something else is currently using the database, I would think you wouldn’t want this to close it anyway) or the readyState should be checked first. Not sure if the same problem occurs with the onerror case.

About this issue

Original URL
State: open
Created 6 years ago
Reactions: 12
Comments: 15 (8 by maintainers)

Most upvoted comments

@trongquyvn I’m getting the same error, it is annoying. I can confirm that the problem occurs even when exists only one tab opened and nothing is operating upon the indexeddb instance.

aislanmaia on Apr 17, 2020

Not sure about the ‘correct’ behavior, maybe it’s situational, but in my case I think I would want to leave it open and reject the drop request if the db is in use. Is there a way to check that the db is not in use before calling dropInstance?

I noticed the docs for readyState mention “Every request starts in the pending state. The state changes to done when the request completes successfully or when an error occurs.” So it sounds like the onerror case should work as-is and only the onblocked case would have this problem. For that I would propose to just reject without attempting to close the db. I can make a PR if you want to go with that, otherwise I should probably leave it to someone else to look into implementing the more complex behavior as I’m not very familiar with the indexedDB API.

One other thing I noticed, the e argument of the handler is actually an Event rather than an Error object, so reject warns that it should only be called with an Error. In the case of onerror the error should be accessible from req.error, but for the blocked handler there is no available Error object as far as I can tell.

AdamStone on Mar 22, 2018