Happy to debug it if you give me some points how to start, as I said I can repro it pretty easily now. This bug is really killing us, please tell me whatever more info you need to address this. Now another strange issue happens here as during writes I get some "UnknownError: An internal error was encountered in the Indexed Database server", the retry logic trigger, but on the next write request I got ConstraintError, as the data was actually written into indexeddb store previously. I also got some kind of failsafe mechanism in place as I automatically retry failed writes a few times. While this is a bit odd way, our users have a lot of trouble because of this, so I guess it just requires some nice timing with putting the app to background. Eventually I get a "Failed to execute 'transaction' on 'IDBDatabase': The database connection is closing." Just start writing records into indexeddb, put the app into background, wait a bit, then repeat, sometimes rapidly switch between foreground and background. I can not reproduce it by normal usage, but recently I found a pretty reliable way to trigger it. I still see a *lot* of these on latest iOS with our app. And you should expect IDB to work if you refresh page and load again.įailed to execute 'transaction' on 'IDBDatabase': The database connection is closing. If that's the case, you should see crash report about. We do have bug report about network process crashing when backgrounding Safari because database file cannot be locked during process suspension. > somebody could acknowledge that this bug has been seen and is beingĭoes IDB behave correctly after you put Safari foreground and refresh the web page? > Given there are seemingly no workarounds, it would be very helpful if > was encountered in the Indexed Database server" error. > the foreground, but then it is too late and you get the "An internal error The event arrives only after restoring Safari to > where the bug repros, no visibilitychange event is received before Safari is > operations when visibilitystate = false does not work because in the case Listening to visibilitychange events and attempting to stop queuing > "UnknownError: Connection to Indexed Database server lost. Re-opening the database after hitting this bug results in an > As an update, I've tried a couple workarounds which do not work: (In reply to Michael Lehenabuer from comment #5) Given there are seemingly no workarounds, it would be very helpful if somebody could acknowledge that this bug has been seen and is being investigated.
I've uploaded a modified repro at which contains these workarounds and additional logging. The event arrives only after restoring Safari to the foreground, but then it is too late and you get the "An internal error was encountered in the Indexed Database server" error. Listening to visibilitychange events and attempting to stop queuing operations when visibilitystate = false does not work because in the case where the bug repros, no visibilitychange event is received before Safari is paused in the background. Re-opening the database after hitting this bug results in an "UnknownError: Connection to Indexed Database server lost. Thanks!Īs an update, I've tried a couple workarounds which do not work:ġ. Let me know if you need anything else to investigate. Subsequent transactions fail saying that IndexedDb is closing, and if you try to open IndexedDb again, the request just hangs. put onerror – UnknownError: An internal error was encountered in the Indexed Database serverĪt this point, IndexedDb is completely broken. If you look in the JS Console you'll see: On my iPhone 6S it usually happens within ~5 tries most I've had to do is ~12.Įventually the number on the page will stop incrementing. Repeat steps 2 and 3 until number on the page stops incrementing. Open safari again (just tap the app icon).Ĥ. If you send safari to the background repeatedly while it's running, you'll hit the bug easily.ģ. I've created a small repro page that just creates an IndexedDb transaction, does 10 writes, and repeats every 100ms. This problem is being reported by more and more Firestore customers.