-
-
Notifications
You must be signed in to change notification settings - Fork 641
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
Opening IndexdDB exception #543
Comments
That exception happens when your browser's database is corrupt. Can happen for various reasons depending on browser. I've seen this error very rarely. What OS / browser are you on? |
Hi, |
Google Chrome has a stable implementation except that it fails silently on quota exceeded. Make sure your DB has not reached the quota limit for your site. Other than that, I could only think of a corrupt hard disk or broken Google Chrome installation. |
Hi @dfahlander, I need to bring this topic up again because the The MacBook of a colleague restarted unexpectedly while he used a web application with Dexie (IndexedDB). After the restart he reopened the web application and got the error. So it looks like the unexpected MacBook restarted ruined the database (which can now no longer be used). Does IndexedDB support database journaling at all or is there any other activity that can be done to prevent such data loss? Can the IndexedDB get repaired? |
There is nothing about disaster recovery in the indexedDB standard what I know of. |
@dfahlander I am also facing this error when performing the delete operation. is the above issue resolved in newer versions or still exist ? we are using version
|
I am able to replicate this error consistently in Chrome 118.0.5993.70 using a very specific set of steps:
The problem does not occur when:
The code pen editor page is here: https://codepen.io/walexander/pen/oNmBWPy |
It sounds marvelous that you found a way to reproduce this. Hopefully this repro could help chromium devs to fix the issue, but I'll start by verifying this and that it's not a Dexie issue before filing it further to the chromium bug tracker. |
I tested the repro and it fails with UnknownError every time I repeat that procedure. I also use Chrome 118.0.5993.70 (on Arm64 (mac)). I can confirm this is not a bug in dexie but a Chromium bug that need to be reported in Chromium bug tracker. The good news is that the issue could be worked around by catching "UnknownError" and retry opening the database. I implemented the workaround in dexie and repeated the repro 10-15 times and the repro never failed to reopen the database the 2nd time so the workaround seems to solve this - at least when reproduced as described in the repro. Immediately after clearing the site data, another chrome-issue is also being hit (#613) - that the call to db.transaction() fails with "InvalidState". This issue has already a workaround - so that dexie is able to reopen the database and retry the call to db.transaction(). Thanks to that workaround, the database succeeds to reopen the database when clicking the plus icon after clearing site data. After refreshing page we get the "UnknownError" instead, but by catching "UnknownError" from db.open() and doing a similar workaround there (retry db.open()) it seems to be successful to workaround both issues. A new version of dexie@3 and dexie@4 will be out soon with the workaround. It would be great if someone could report this issue to chromium bug tracker. Please post here a link to reported bug and refer to the repro we have in this bug. There's already a similar issue since 2020 in chromium bug tracker. |
A workaround for this issue was released in dexie@4.0.1-beta.2. The workaround is not released for dexie@3.x (stable) yet but has been cherry-picked there and will be released soon. |
It's amazing to see that Dexie continues to receive updates even after so many years. Keep up the good work, @dfahlander! 💪 Dexie is still an integral part of Wire's messenger. ⭐ |
I get this error too with Dexie 3.2.4, macOS, Chrome 124.0.6367.93 (arm64). I encounter it after using the browser function to delete all website data and reloading the page. Will the workaround still be released to Dexie 3? |
It was released in 3.2.5. Latest 3.x is now 3.2.7. |
Oh that's great, thank you, I will update! |
Closes #1416 - All Service Worker services now have a destroy or close method; - Ensure all Services' listeners, connections and connections are properly removed on destroy; - Removed all logic that forced the Service Worker to stay awake; - Ping JSONRPC event no longer triggers Keep Awake logic; - Allow service worker to be paused and resumed; - Ensure the Service Worker is properly restarted on update; - PopupServer instances will automatically self-destroy after being used, as they can be re-created when needed; - Avoid permanent interval by only starting auto-lock timer when wallet is unlocked; - Avoid permanent Content Script interval/looped calls by opening connection, if closed, when needed; - Previously if any of the services threw an exception the service worker would stop working, now it restarts and resumes execution - Updated Dexie to 3.2.7, which brings fixes around a DB corruption [bug](dexie/Dexie.js#543) - Updated Fuel SDK to 0.94.5 - Fixed error in parsing headers, in Provider's middleware, when the selected network goes offline.
- Remove manual reload of wallet. - Fixed IndexDB [randomly rejecting TXs](dexie/Dexie.js#613) and or [failing to open](dexie/Dexie.js#543) - Fixes error where Dexie would allow insertion of entries with duplicate primary keys/ids. - Upgrade Dexie to V4
Hi,
What is reason of opening DB exception "UnknownError: Internal error opening backing store for indexedDB"?
As I checked, When a transaction is running, any try to open DB raise this exception.
I run transaction with mode r!,rw!.
also when my transaction is ongoing , isOpen method return false value .
The text was updated successfully, but these errors were encountered: