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

Opening IndexdDB exception #543

Closed
mgovahi opened this issue May 31, 2017 · 11 comments
Closed

Opening IndexdDB exception #543

mgovahi opened this issue May 31, 2017 · 11 comments

Comments

@mgovahi
Copy link

mgovahi commented May 31, 2017

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 .

@dfahlander
Copy link
Collaborator

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?

@mgovahi
Copy link
Author

mgovahi commented Jul 24, 2017

Hi,
My OS is Windows 10 and browser Google Chrome.

@dfahlander
Copy link
Collaborator

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.

@bennycode
Copy link
Contributor

Hi @dfahlander, I need to bring this topic up again because the UnknownError with message "Internal error opening backing store for indexedDB.open." occurred again.

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?

@dfahlander
Copy link
Collaborator

There is nothing about disaster recovery in the indexedDB standard what I know of.

@ankit-prajapati-26
Copy link

@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 3.2.2

db.devicelogs
    .where(schema.deviceLogs)
    .between(startRange, endRange, true, true)
    .delete()
    .catch((e) => {
      if (e && e.name !== 'OpenFailedError') {
        console.log("Error: ", e)
      }
    });

@Walexander
Copy link

Walexander commented Nov 6, 2023

I am able to replicate this error consistently in Chrome 118.0.5993.70 using a very specific set of steps:

  1. On this page, Click + to add a couple items to the database.
  2. Clear all Cookie & Site Data. (Click the Lock icon to the left of the URL bar and go to Cookies & Site Data -> Manage. Then click the Trash button.)
  3. Without reloading the page click the + button again. The count should go to 1 and, except for a warning in the console, all will appear normal. Clicking + multiple times will continue to increment the count.
  4. At this point, reloading the page will lead to an UnknownError Internal error opening backing store for indexedDB.open.
  5. Reloading the page again will work -- although edits made after the previous deletion are lost.

The problem does not occur when:

  1. The page is reloaded after clearing Site data without pressing the button (creating another Dexie transaction).
  2. Manually deleting the database via Dev Tools - only occurs when using the Clear Cookie & Site Data.

The code pen editor page is here: https://codepen.io/walexander/pen/oNmBWPy

@dfahlander
Copy link
Collaborator

dfahlander commented Nov 6, 2023

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.

@dfahlander
Copy link
Collaborator

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.

@dfahlander
Copy link
Collaborator

dfahlander commented Nov 29, 2023

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.

@bennycode
Copy link
Contributor

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. ⭐

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

5 participants