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

db.on('error') event is not available #934

Open
scazzy opened this issue Nov 13, 2019 · 4 comments
Open

db.on('error') event is not available #934

scazzy opened this issue Nov 13, 2019 · 4 comments

Comments

@scazzy
Copy link

scazzy commented Nov 13, 2019

image

I'm trying to fix the DatabaseClosedError (db con closes randomly), and wanting to add a global handler for the same.

I tried adding db.on('error', handler), but it throws error. There's no 'error' event to subscribe to.

Using Dexie 2.0.3 via npm. Also tried with upgraded version.

Also, if you've a better solution for handling randomly closing db connection, would be helpful.
LocalForage and PouchDB handles these internally, but guess Dexie doesn't yet. If you can point out where to change, I can help with a PR as well.

@dfahlander
Copy link
Collaborator

It's obsolete since version 2.0: https://dexie.org/docs/Deprecations#dexieonerror--dbonerror

I've not seen there have been any problem with randomly closed database connections in IndexedDB. Though, if another Dexie instance is upgrading the version, all existing Dexie instances will close unless overriding the versionchange event to capture that and close/repopen the db from there.

@scazzy
Copy link
Author

scazzy commented Nov 13, 2019

So the DB connection seem to close when app is open for long, maybe went on sleep and re-opened. We've noticed this often, primarily for long sessions.

There were issues reported on other libs as well, eg
tutao/tutanota#452
localForage/localForage#581
localForage/localForage#694

@dfahlander
Copy link
Collaborator

Ok. I see there's a reference to #613 also there. It would be nice to get an understanding of how to detect this state and solve it under the hood in dexie. Maybe look into how it is fixed in pouchdb and do something similar in Table._trans - which is the method that all calls will go through.

@adamJLev
Copy link

adamJLev commented Apr 21, 2020

Also dealing with this issue, basically eventually if the page is open long enough DatabaseClosedError happens and any subsequent Dexie queyring after that stops working. This is on the latest Chrome and its been happening for a long time ( at least a year, basically since the beginning of my app), based on my Sentry JS exception logs.

But all that needs to happen is call db.open() to fix that, so I am also looking to put this in a central place.
Ideally Dexie handles this transparently, but for now I'll add a workaround.

Screen Shot 2020-04-21 at 12 44 39 AM

dfahlander added a commit that referenced this issue May 8, 2023
The custom unhandledrejection event propagation is not reliable when native async function throw errors. The event is fired before we have a chance to detect that the error was indeed handled in a later tick.

User code should not rely on unhandledrejection anyway but have it as a debugging tool rather - to detect errors in the code where promises aren't caught properly. Users that use async functions will get the native unhandledrejection functionality anyway, but those who still use promise-based .then()/ .catch() might not get this warning anymore after this commit. However, I believe it's better to not warn when the warning is not correct anyway.

Related issues:
* #1706
* #1689
* #934

Resolves #1684
dfahlander added a commit that referenced this issue May 11, 2023
The custom unhandledrejection event propagation is not reliable when native async function throw errors. The event is fired before we have a chance to detect that the error was indeed handled in a later tick.

User code should not rely on unhandledrejection anyway but have it as a debugging tool rather - to detect errors in the code where promises aren't caught properly. Users that use async functions will get the native unhandledrejection functionality anyway, but those who still use promise-based .then()/ .catch() might not get this warning anymore after this commit. However, I believe it's better to not warn when the warning is not correct anyway.

Related issues:
* #1706
* #1689
* #934

Resolves #1684
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

3 participants