What to do on an UnknownError? (in Electron)

[bennycode]

In my application I am getting this error from time to time when accessing the database:

UnknownError: Internal error opening backing store for indexedDB.open.

Is there a best-practice on how to recover from such an error?

[dfahlander]

Generally, that error indicates issues with indexedDB implementation or its backing store. Are you on a technical preview of a certain os? I've only seen this error on the edge browser after having triggered this bug.

[bennycode]

Ok! Good to know! I've seen this bug with Chrome 51 (running inside Electron 1.2.2).

[dfahlander]

This and #269 makes me a bit worried over the stability of indexedDB in Electron. I would very much like to launch Dexie's unit test suite within an electron app to see if it behaves there or not.

[bennycode]

Let's do it! I can hook it up in a blank Electron app and publish the results here. Anything I need to take care of? I am also using Dexie 1.4.1.

[dfahlander]

Thanks, that would be great. I think you could just create a browser view that opens test/run-unit-tests.html. Need to have built it first with npm run build. Please fork Dexie.js and build it with npm install and npm run build (or follow the contributing guide)

[dfahlander]

A second goal would then be to have that included in the package (npm run test:electron should run the tests in an election app). But first let's see what the findings are.

[bennycode]

Hi @dfahlander,

As promised I got the test results from running Dexie inside of Electron.

Test environment

Dexie 1.4.1
Electron 1.2.3
Chromium 51.0.2704.84
node 6.1.0

Test log

electron-dexie-unit-tests.zip

Screenshot

Comment

There are a few warnings but I think these ones are expected. At least I get the exact same warnings when running the test suite inside of my Chrome browser (without Electron).

[dfahlander]

That's good. Thanks a lot for helping out to test this!

:)

[dfahlander]

In your app, are you using multiple browser windows or workers accessing the same database?

[bennycode]

I think during an app update it could happen that there are two instances of Electron at the same time. That could prevent indexedDB.open from doing it's job. Can we force to close the connection of the other instance in this case?

[dfahlander]

Aha. Only if electron behaves well with indexedDB when running multiple instances of electron, we can handle that situation, and dexie already does that in the default behavior of the versionchange event. The old app will close its db to resume the new app's open() request. This only applies when new app has a higher db version. It should be perfectly ok to have multiple db instances running with same db version. Browsers handle it. The question is if electron does...?

[bennycode]

@dfahlander: Today I noticed that my Electron application fails on updates. So whenever my application gets updated and restarts, Dexie fails with the following error: UnknownError: Internal error opening backing store for indexedDB.open..

Is there anything I can do about this? Maybe closing the database connection when my Electron app is closed or something like that?

[dfahlander]

Is it the old or the new instance that fails?

[bennycode]

It's the new instance which fails.

[dfahlander]

You could try closing the db instances in the old version, but indexedDB should not behave like this of it would have been different browser processes. However, I don't know how the upgrade flow is; if files are replaced in the file system while the old process is running. There might be that the physical db file is still locked when you start the new version. Think this needs to be solved outside the scope of Dexie or indexedDB. Is the update system proprietary or are you using any built in updating support in electron?

[bennycode]

For updating the app Electron's autoUpdater is used which works with Squirrel under the hood.

[bennycode]

Update: We found out that the problem is on Electon's site. When there is an update for our Electron app, Electron starts the new app version in the background (while the old version is still open) and then the new Electron version cannot open the database (because the first version locked it). Does this make sense? I think only 1 process can open the database or am I wrong?

[dfahlander]

With Electron, it could be a problem. With Chrome, it's not. It's totally legimite to have two different browser windows accessing the same indexedDB database. But Chrome and other browsers must accomplish this by separating the database facing process from the browser processes and makes sure it never have many database processes running in parallell. Maybe Electron separates the processes too but they obviously fail in replacing the old version when they let the backend process run in parallell with the old one.

Did you find a workaround for it?

[dfahlander]

Do you know if there's an issue at Electron for this yet?

[chrisvanruiten]

Hi All, maybe a bit late. I saw if an electron process is running in the background and you're starting a new electron process, the IndexedDB is locked for the first process. So I get an error: "UnknownError: Internal error opening backing store for indexedDB.open.". When I kill the first process, the error doesn't pop up. I hope it helps for someone!

[dfahlander]

Thanks, @chrisvanruiten for sharing your experience with Electron and IndexedDB. This is what I've suspected. I wish Electron would have hosted its indexedDB access through a common process, as I believe Chrome probably does it.

[trusktr]

@chrisvanruiten was right. Making sure I had one Electron running instead of two made it work again.

[ElchinIsmayilov]

this is still occur on electron with chrome
OS: Win7
Electron: 1.8.4
Chrome: 59.0.3071.115,
Dexie: 2.0.1

[dfahlander]

The Electron team has a response to this issue: electron/electron#10792 (comment)

Following that advice leads to a deprecated API app.makeSingleInstance(), replaced with app.requestSingleInstanceLock()

Conclusion

Electron apps have to be single instance if using any common resource (like indexeddb for example). This is simply accomplished by calling app.requestSingleInstanceLock(). Users can still double click a desktop icon (on Windows) or right-click in Dock and choose "New window" (on Mac). In your callback to app.on('second-instance', ...) you decide what should happen when a user starts a second instance. You could either focus the main window, or launch another window within the same app instance.

[yyccQQu]

The Electron team has a response to this issue: electron/electron#10792 (comment)

Following that advice leads to a deprecated API app.makeSingleInstance(), replaced with app.requestSingleInstanceLock()

Conclusion

Electron apps have to be single instance if using any common resource (like indexeddb for example). This is simply accomplished by calling app.requestSingleInstanceLock(). Users can still double click a desktop icon (on Windows) or right-click in Dock and choose "New window" (on Mac). In your callback to app.on('second-instance', ...) you decide what should happen when a user starts a second instance. You could either focus the main window, or launch another window within the same app instance.

- https://www.electronjs.org/docs/v14-x-y/api/app

// 第二个实例打开时执行的程序
const { app } = require('electron')
let myWindow = null

const gotTheLock = app.requestSingleInstanceLock()

if (!gotTheLock) {
  app.quit()
} else {
  app.on('second-instance', (event, commandLine, workingDirectory) => {
    // Someone tried to run a second instance, we should focus our window.
    if (myWindow) {
      if (myWindow.isMinimized()) myWindow.restore()
      myWindow.focus()
    }
  })

  // Create myWindow, load the rest of the app, etc...
  app.whenReady().then(() => {
    myWindow = createWindow()
  })
}