Bug 273827 – REGRESSION (iOS 17.4): IndexedDB failing with "UnknownError: Connection to Indexed Database server lost."

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: WebCore Misc.

[Luke Abbott]

Starting with iOS 17.4, my website's connection to IndexedDB will spontaneously close and fail to reopen, throwing this error:

  "UnknownError: Connection to Indexed Database server lost. Refresh the page to try again"

It's a widespread issue, with hundreds of users (a high percentage of my iOS user base) affected. It started with iOS 17.4 and appears to still be an issue in iOS 17.5. It is causing DATA LOSS for users as their data is not being persisted. 

I've also started getting "UnknownError: Attempt to get a record from database without an in-progress transaction" more frequently starting with iOS 17.4, though maybe 5% as many times as the "connection lost" error.

See issue 197050 for reports from other users affected by this bug; I started a new bug report because this is a new bug. 

It is also being reported elsewhere on the web:
- Same bug: https://github.com/ionic-team/ionic-storage/issues/317
- Same bug: https://github.com/ionic-team/capacitor/issues/7439
- Different issue (perhaps) but also new to iOS 17.4 and related to IndexedDB: https://github.com/firebase/firebase-js-sdk/issues/8068

[Radar WebKit Bug Importer]

<rdar://problem/127700951>

[Brady Eidson]

This error happens when WebKit's Networking process crashes.

To find out why it is crashing for you, we'd need to see crash logs.

Are you familiar with how to get at them? In Settings->Privacy->Analytics?

[Brady Eidson]

Or if you plug in your phone and sync to a Mac, on the Mac:
~/Library/Logs/CrashReporter/MobileDevice/

[Lincoln Baxter, III]

This also affects us. The IndexedDB should be able to restart and reconnect if the networking process crashes. The rest of the site continues to function just fine, but without access to the database until the entire device/webkit process is restarted. So users essentially keep operating on the site but experience inconsistent behavior as underlying components fail to save or load DB data.

This results in a really bad user experience, even with failover to local storage.

[Sihui Liu]

(In reply to Lincoln Baxter, III from comment #4)
> This also affects us. The IndexedDB should be able to restart and reconnect
> if the networking process crashes. The rest of the site continues to
> function just fine, but without access to the database until the entire
> device/webkit process is restarted. So users essentially keep operating on
> the site but experience inconsistent behavior as underlying components fail
> to save or load DB data.
> 
> This results in a really bad user experience, even with failover to local
> storage.

Site can listen to close event (https://developer.mozilla.org/en-US/docs/Web/API/IDBDatabase/close_event) to find out when the database connection is closed due to process crash or other issues and reopen database (`indexedDB.open`), so it can access the database again.

[Luke Abbott]

(In reply to Sihui Liu from comment #5)
> Site can listen to close event
> (https://developer.mozilla.org/en-US/docs/Web/API/IDBDatabase/close_event)
> to find out when the database connection is closed due to process crash or
> other issues and reopen database (`indexedDB.open`), so it can access the
> database again.

Unfortunately, it is impossible to re-open the database connection after this issue occurs, so listening to the close event won't help.

I have thus far been unable to catch the error locally since getting the instruction to collect crash logs. It's still happening just as often in production, though.

Regardless of why the networking process is crashing, shouldn't it be possible to reconnect to IndexedDB after network access is restored? As Lincoln was saying, the rest of the site continues to work (including the remote server connection) but it's impossible to reconnect to IndexedDB.

[Sihui Liu]

(In reply to Luke Abbott from comment #6)
> (In reply to Sihui Liu from comment #5)
> > Site can listen to close event
> > (https://developer.mozilla.org/en-US/docs/Web/API/IDBDatabase/close_event)
> > to find out when the database connection is closed due to process crash or
> > other issues and reopen database (`indexedDB.open`), so it can access the
> > database again.
> 
> Unfortunately, it is impossible to re-open the database connection after
> this issue occurs, so listening to the close event won't help.
> 
> I have thus far been unable to catch the error locally since getting the
> instruction to collect crash logs. It's still happening just as often in
> production, though.
> 
> Regardless of why the networking process is crashing, shouldn't it be
> possible to reconnect to IndexedDB after network access is restored? As
> Lincoln was saying, the rest of the site continues to work (including the
> remote server connection) but it's impossible to reconnect to IndexedDB.

By "it is impossible to re-open the database connection", do you mean the `indexedDB.open()` fails after the connection lost error? If so, this is a different issue than the error itself. Site should be able to build IndexedDB connection to the relaunched network process on open().

Does everything work correctly if you reload the page?

[Luke Abbott]

> By "it is impossible to re-open the database connection", do you mean the
> `indexedDB.open()` fails after the connection lost error? If so, this is a
> different issue than the error itself. Site should be able to build
> IndexedDB connection to the relaunched network process on open().
> 
> Does everything work correctly if you reload the page?

Yes to both.

Once whatever is breaking breaks, and a database operation fails (generally with an InvalidStateError I think), the library I'm using (Dexie v4) detects this and calls `db.close()` followed by `db.open()`, with up to 3 attempts at restoring the connection. This behavior was initially implemented in Dexie because Chrome started randomly dropping the database connection around v51. It was effective for that issue since the connection could be restored, but it cannot restore the connection with this new iOS 17.4 issue. 

I am not 100% sure simply reloading the page (versus restarting the process) fixes it, but I *believe* it does based on other devs' reports. Of course, the problem with that approach is a) it interrupts the user's flow and b) any data not yet persisted to IndexedDB is lost.

[Lincoln Baxter, III]

> By "it is impossible to re-open the database connection", do you mean the `indexedDB.open()` fails after the connection lost error? If so, this is a different issue than the error itself. Site should be able to build IndexedDB connection to the relaunched network process on open().

Calling `.open()` does not work once this occurs.

> Does everything work correctly if you reload the page?

We believe the error persists across page reloads. Our users have reported closing and re-opening our app (with embedded WebView), but error keeps occurring until their iOS device is fully restarted.

[Sihui Liu]

(In reply to Lincoln Baxter, III from comment #9)
> > By "it is impossible to re-open the database connection", do you mean the `indexedDB.open()` fails after the connection lost error? If so, this is a different issue than the error itself. Site should be able to build IndexedDB connection to the relaunched network process on open().
> 
> Calling `.open()` does not work once this occurs.
> 
> > Does everything work correctly if you reload the page?
> 
> We believe the error persists across page reloads. Our users have reported
> closing and re-opening our app (with embedded WebView), but error keeps
> occurring until their iOS device is fully restarted.

By ".open() does not work", do you mean it returns error, or no event (success, error, block, etc) is fired, or it returns success but the opened connection will be lost again (e.g. the UnknownError happens soon)?

Also, do you receive close event on previous connection which gets the UnknownError?

[Brian Glaeske]

We're seeing this in our Capacitor app as well and our users are experiencing data loss.

[Luke Abbott]

(In reply to Sihui Liu from comment #10)
> By ".open() does not work", do you mean it returns error, or no event
> (success, error, block, etc) is fired, or it returns success but the opened
> connection will be lost again (e.g. the UnknownError happens soon)?

It looks like the call to .open() errors with "UnknownError: Connection to Indexed Database server lost. Refresh the page to try again".

I say this because every error log I'm looking at in Sentry is hitting a line in Dexie[1] that writes to the console when .open() fails.

That said, I am not 100% sure whether it's the call to .open() that fails, or the following read of the database that Dexie does immediately to determine schema. But I strongly suspect it is the former. (Not easy for me to deploy a test right now.)

> Also, do you receive close event on previous connection which gets the
> UnknownError?

It does not appear that the close event is being fired. Rather, Dexie is trying to reopen the connection because some operation hits an InvalidStateError which prompts the library to close-and-reopen the connection.

[1]: https://github.com/dexie/Dexie.js/blob/a09b699dfa5253faad604553c15c34d76f05b167/src/classes/dexie/dexie-open.ts#L137

[Stéphane Magnenat]

Any update on this bug? The last comment was 2 months ago. This is affecting our users (https://cand.li) with data loss.

[Stéphane Magnenat]

A short question: does anyone has a reliable way to reproduce the issue? Is there a Safari/iOS settings or extension needed for it to appear?

[Alexey Proskuryakov]

We believe that this is fixed in iOS 17.6 beta (and iOS 18 beta) with an OS change outside WebKit.

Please file new bugs if you still see similar issues with those or newer releases, as continuing the discussion here will cause significant confusion to engineering (please feel welcome to mark the new bug reports as See Also, of course).

[Lincoln Baxter, III]

@Alexey Thank you for the update. We very much look forward to having this resolved. Perhaps a bit late, I did notice some interesting metadata in our error reporting stats.

It appears this bug happens mostly when the browser reports itself as "Apple Mail 605.1.15"

See screenshots.

[Lincoln Baxter, III]

Created attachment 471973 [details]
Metadata from error logging

[Lincoln Baxter, III]

Created attachment 471974 [details]
Metadata from error logging -- full list

[David Fahlander]

This problem still occurs with iOS 18.0.1 (22A3370). I'm in contact with a Dexie.js customer that sees this problem more often since iOS 17.4. There are also open issues in Dexie regarding this.

https://github.com/dexie/Dexie.js/issues/2008
https://github.com/dexie/Dexie.js/issues/543

[Alexey Proskuryakov]

Thank you for the update.

Please file new bugs if you still see similar issues with those or newer releases, as continuing the discussion here will cause significant confusion to engineering (please feel welcome to mark the new bug reports as See Also, of course).