Bug 197050 – IndexedDB: An internal error was encountered in the Indexed Database server

• Component: Website Storage
• Status: RESOLVED CONFIGURATION CHANGED

We have received reports from the users of the Firebase SDK for Firestore (see https://github.com/firebase/firebase-js-sdk) that they are seeing the following exception starting with iOS 12:

"An internal error was encountered in the Indexed Database server"

The user report states that bringing the Web app into the background and back into the foreground triggers this crash. More details can be found here: https://github.com/firebase/firebase-js-sdk/issues/1670

There are some other reports that this issue is related to storing Uint8Arrays in Object Stores that use auto-incrementing keys. While we do use auto-incrementing keys in Firestore, we do not store Uint8Arrays.

[Radar WebKit Bug Importer]

<rdar://problem/50005532>

[David Fahlander]

Got Dexie issue related to this one: https://github.com/dfahlander/Dexie.js/issues/832

[David Fahlander]

Related Cordova issue:

https://github.com/ionic-team/cordova-plugin-ionic-webview/issues/354

[Michael Lehenabuer]

This problem is being reported by more and more Firestore customers. I've created a small repro page that just creates an IndexedDb transaction, does 10 writes, and repeats every 100ms.  If you send safari to the background repeatedly while it's running, you'll hit the bug easily.

Repro steps:

1. Open http://mike-shared.firebaseapp.com/ios-crash.html in iOS 12.2 Safari 
2. Press Home button.
3. Open safari again (just tap the app icon).
4. Repeat steps 2 and 3 until number on the page stops incrementing. On my iPhone 6S it usually happens within ~5 tries; most I've had to do is ~12.

Result:
Eventually the number on the page will stop incrementing. If you look in the JS Console you'll see:

[Error] put onerror – UnknownError: An internal error was encountered in the Indexed Database server
	(anonymous function) (ios-crash.html:63)

At this point, IndexedDb is completely broken.  Subsequent transactions fail saying that IndexedDb is closing, and if you try to open IndexedDb again, the request just hangs.

Let me know if you need anything else to investigate.  Thanks!

[Michael Lehenabuer]

As an update, I've tried a couple workarounds which do not work:

1. Re-opening the database after hitting this bug results in an "UnknownError: Connection to Indexed Database server lost. Refresh the page to try again."

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

I've uploaded a modified repro at http://mike-shared.firebaseapp.com/ios-crash2.html which contains these workarounds and additional logging.

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. Thanks!

[tgangso]

This is a serious issue and should get top priority.

[Sihui Liu]

(In reply to Michael Lehenabuer from comment #5)
> As an update, I've tried a couple workarounds which do not work:
> 
> 1. Re-opening the database after hitting this bug results in an
> "UnknownError: Connection to Indexed Database server lost. Refresh the page
> to try again."
> 
> 2. 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.  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.
> 
> I've uploaded a modified repro at
> http://mike-shared.firebaseapp.com/ios-crash2.html which contains these
> workarounds and additional logging.
> 
> 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. Thanks!

Hi Michael,

Thank you for the bug report.

Does IDB behave correctly after you put Safari foreground and refresh the web page?
We do have bug report about network process crashing when backgrounding Safari because database file cannot be locked during process suspension. We have proposed a fix(https://bugs.webkit.org/show_bug.cgi?id=196372).

If that's the case, you should see crash report about com.apple.WebKit.Networking. And you should expect IDB to work if you refresh page and load again.

Thanks!

[Michael Lehenabuer]

Hi Sihui,

Thanks very much for the response.  From the description, https://bugs.webkit.org/show_bug.cgi?id=196372 does sound very much like it could be the root cause which is great news. IDB *does* work fine after refreshing the page.

Where exactly would I look to see the com.apple.WebKit.Networking crash report to confirm that it is happening as well?

Thanks,
Michael

[Chris Dumez]

(In reply to Michael Lehenabuer from comment #8)
> Hi Sihui,
> 
> Thanks very much for the response.  From the description,
> https://bugs.webkit.org/show_bug.cgi?id=196372 does sound very much like it
> could be the root cause which is great news. IDB *does* work fine after
> refreshing the page.
> 
> Where exactly would I look to see the com.apple.WebKit.Networking crash
> report to confirm that it is happening as well?

The crash report should show up under:
Settings > Privacy > Analytics > Analytics Data.

[Michael Lehenabuer]

Created attachment 369304 [details]
com.apple.WebKit.Networking crash report for IndexedDb background issue

Thanks. I do see a number of crash reports for com.apple.WebKit.Networking from 2019-04-24 and 2019-04-25 which is when I was originally reproducing the bug. Strangely though, if I reproduce the bug again now (using my http://mike-shared.firebaseapp.com/ios-crash.html repro) I do *not* see a new crash report, even though the bug still reproduces.  I'm not sure what the difference is.

I've attached one of the reports from 04-25 if you want to verify it is the same bug.  I can't explain why I'm not getting new crash reports though.

Thanks!

[Jason Kealey]

I could reproduce easily on iOS 12.2 yesterday on Safari, Chrome and Firefox using 
http://mike-shared.firebaseapp.com/ios-crash.html

Today, on 12.3, I am unable to make any of the browsers crash right after upgrading iOS. I have not done extensive testing to see if this persists after prolonged browser use.

[Michael Lehenabuer]

Thanks Jason!  It seems like everything is adding up that this is a dupe of https://bugs.webkit.org/show_bug.cgi?id=196372 and has been addressed in iOS 12.3 which is great news.  So I think you can probably go ahead and close this issue.  Thanks!

[Stefan Sechelmann]

The issue is still present in 12.3 stable as observed today in a WKWebView: first occurs

AbortError: UnknownError An internal error was encountered in the Indexed Database server Mozilla/5.0 (iPhone; CPU iPhone OS 12_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko)

then any further access would result in

InvalidStateError: Failed to execute 'transaction' on 'IDBDatabase': The database connection is closing. Mozilla/5.0 (iPhone; CPU iPhone OS 12_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko)

I will observe the stats for our app for the next days.

[Sihui Liu]

Hi all,

The fix for https://bugs.webkit.org/show_bug.cgi?id=196372 is not in iOS(iOS 12.3) yet, so you may still see the bug. For temporary workaround, you could try reloading page or re-opening the IDB database after you encounter the error.

The bug leads to process crash, so the old IDB database connection to crashed process would fail and we need to establish a new connection by re-opening.

[Michael Lehenabuer]

Thanks Sihui,

Do you know what release it's going to be in?  We're planning to disable our usage of IndexedDb on iOS 12.2 to avoid this crash. I was really hoping we'd only have to disable it for iOS 12.2, but if the fix isn't going to make it into iOS 12.3 we may need to reevaluate.

[Sihui Liu]

(In reply to Michael Lehenabuer from comment #15)
> Thanks Sihui,
> 
> Do you know what release it's going to be in?  We're planning to disable our
> usage of IndexedDb on iOS 12.2 to avoid this crash. I was really hoping we'd
> only have to disable it for iOS 12.2, but if the fix isn't going to make it
> into iOS 12.3 we may need to reevaluate.


Hi Michael,

We are not allowed to comment on future iOS release. If you want to know whether the fix is in a released iOS build (including beta), I can tell you that. The fix is not in any iOS build yet.

[Johan Baversjo]

(In reply to Sihui Liu from comment #16)
> (In reply to Michael Lehenabuer from comment #15)
> > Thanks Sihui,
> > 
> > Do you know what release it's going to be in?  We're planning to disable our
> > usage of IndexedDb on iOS 12.2 to avoid this crash. I was really hoping we'd
> > only have to disable it for iOS 12.2, but if the fix isn't going to make it
> > into iOS 12.3 we may need to reevaluate.
> 
> 
> Hi Michael,
> 
> We are not allowed to comment on future iOS release. If you want to know
> whether the fix is in a released iOS build (including beta), I can tell you
> that. The fix is not in any iOS build yet.

Hello Sihui,
Thank you for your fix.
Is it the case that this fix is also not in iOS 12.4 beta 2?

[Sihui Liu]

(In reply to Johan Baversjo from comment #17)
> (In reply to Sihui Liu from comment #16)
> > (In reply to Michael Lehenabuer from comment #15)
> > > Thanks Sihui,
> > > 
> > > Do you know what release it's going to be in?  We're planning to disable our
> > > usage of IndexedDb on iOS 12.2 to avoid this crash. I was really hoping we'd
> > > only have to disable it for iOS 12.2, but if the fix isn't going to make it
> > > into iOS 12.3 we may need to reevaluate.
> > 
> > 
> > Hi Michael,
> > 
> > We are not allowed to comment on future iOS release. If you want to know
> > whether the fix is in a released iOS build (including beta), I can tell you
> > that. The fix is not in any iOS build yet.
> 
> Hello Sihui,
> Thank you for your fix.
> Is it the case that this fix is also not in iOS 12.4 beta 2?

Yes, it's not in iOS 12.4 beta 2.

[Tim]

Can anyone confirm that the fix is in the iOS 12.4 beta 3 or, asking in advance, the first iOS 13 beta?

[Sihui Liu]

Fix is in iOS 13 beta, you should not see the same crash or IDB error when bringing backgrounded app to foreground.

[E.J. Daly]

Hi Sihui,

Can you confirm if this fix is also in iOS 12.4 please?

Thanks

[Sihui Liu]

(In reply to E.J. Daly from comment #21)
> Hi Sihui,
> 
> Can you confirm if this fix is also in iOS 12.4 please?
> 
> Thanks

Hi E.J, this is not in iOS 12.4.

[E.J. Daly]

Thanks Sihui,

Is there still a possibility of it getting to iOS 12 or has that been finalized yet? 

If not, it's going to be remain an issue we need to consider for iPhone ~6 users I guess?

The issue itself is particularly problematic for apps added to home screen, which can't be refreshed / forced to quit in iOS12. So if the app gets into a bad state because of this - it's very difficult to get out of it (without restarting the phone or doing a memory reset or re-installing the PWA)

[Sihui Liu]

(In reply to E.J. Daly from comment #23)
> Thanks Sihui,
> 
> Is there still a possibility of it getting to iOS 12 or has that been
> finalized yet? 
> 
> If not, it's going to be remain an issue we need to consider for iPhone ~6
> users I guess?
> 
> The issue itself is particularly problematic for apps added to home screen,
> which can't be refreshed / forced to quit in iOS12. So if the app gets into
> a bad state because of this - it's very difficult to get out of it (without
> restarting the phone or doing a memory reset or re-installing the PWA)

That should be finalized. Can you try re-opening the database?

[Mark]

We have been struggling with this problem on our WKWebview based app which has local sync database. The error is resulting in the loss of customer's data so is pretty serious for us, we have tried trapping it and reconnecting to the IndexedDb but this does not seem to resolve the issue. The only way currently to move on is to completely reload the webview but doing this means we are loosing the state that needs to be saved to IndexedDb. Many of our users use older iOS devices so it needs to be a iOS 12 fix for us, otherwise we will have to inform a large number of our users that due to a iOS 12 bug we can no longer support their device!

[Jake Teton-Landis]

On iOS 13 beta, we're still seeing the following error:

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

Is this expected to be fixed? Is there another ticket which tracks the "...Refresh the page to try again" bug?

Like Mark, I work on an app that uses IndexedDB to persist critical user edits, so we cannot "refresh the page" without losing in-memory data.

[Tim]

Sihui Liu, can you confirm the bug (or correctly the bug for id 196372) is fixed and available in the iOS 13 GM?

Thanks!

[Sihui Liu]

(In reply to Tim from comment #27)
> Sihui Liu, can you confirm the bug (or correctly the bug for id 196372) is
> fixed and available in the iOS 13 GM?
> 
> Thanks!

Hi,

The fix for bug (https://bugs.webkit.org/show_bug.cgi?id=196372) is in iOS 13 GM Seed. It should fix the issue where IDB internal error showed up when backgrounding app and then bringing it to foreground.

We are seeing new issues with iOS 13 and believe that the patch for this issue may be one of the causes. It appears that the following sequence of operations is now possible:

1) The Firestore SDK opens a new IndexedDb transaction/
2) The Safari tab goes in the background.
3) WebKit terminates the network, which stops the IDBServer (https://trac.webkit.org/browser/trunk/Source/WebKit/NetworkProcess/NetworkProcess.cpp#L2117)
4) The app goes back in the foreground and resumes its operation. Firestore tries to use the transaction it opened in step 1 and receives "Attempt to get a record from database without an in-progress transaction"

I filed https://bugs.webkit.org/show_bug.cgi?id=202705

[zac spitzer]

I'm seeing this problem with multiple iOS 13 users, from what I can tell, 
there were no open transactions before the browser went to the background.

The tab gets focussed again after a few minutes and then "Connection to Indexed Database server lost." gets thrown next time IndexedDB is accessed, 

via a new open, new transaction, put(), no auto incrementing keys in use.

[Piotr]

I can confirm that this bug still exists in iOS 13.3.1.

[Brady Eidson]

Whatever is still happening here to some users is different than what was originally reported.

So for those who still see this happen on iOS 13.x - Please attach com.apple.WebKit.Networking crash logs.

[Istvan Tabanyi]

Created attachment 405919 [details]
Failed to execute 'transaction' on 'IDBDatabase': The database connection is closing.

I still see a *lot* of these on latest iOS with our app. I can not reproduce it by normal usage, but recently I found a pretty reliable way to trigger it. Just start writing records into indexeddb, put the app into background, wait a bit, then repeat, sometimes rapidly switch between foreground and background. Eventually I get a "Failed to execute 'transaction' on 'IDBDatabase': The database connection is closing."
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.

I also got some kind of failsafe mechanism in place as I automatically retry failed writes a few times. 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.

This bug is really killing us, please tell me whatever more info you need to address this. Happy to debug it if you give me some points how to start, as I said I can repro it pretty easily now.

[zac spitzer]

which version of iOS? 

I have only seen this from users running older versions, 13.5.1 being the latest

[Istvan Tabanyi]

13.5.1, I got at least three different AbortError and UnknownError in the last hour with the method I described. I am sure about the two errors which I mentioned.

[zac spitzer]

I'm afraid your only option is to sniff the UA and tell em to upgrade their iOS

[Istvan Tabanyi]

Sorry, but upgrade to where? I can reproduce it on 13.5.1.

[zac spitzer]

13.6 is the latest release of iOS

[Istvan Tabanyi]

Oh, nice, I saw only 13.5.1, restarted the phone and the update appeared. I will try to reproduce it on 13.6, cheers.

[Simon Bluhm]

Created attachment 406874 [details]
UnknownError: An internal error was encountered in the Indexed Database server

[Simon Bluhm]

I have not been able to consistently reproduce this and not sure what exactly is causing this but users of my app have reported several "Failed to execute 'transaction' on 'IDBDatabase': The database connection is closing" errors.

To investigate further, I added the IDBDatabase close event to my code and it seems to fire a lot on iOS 13.3.1 but I have also seen it on iOS 13_6. This is usually on opening the app after a period of inactivity. The code now automatically reloads the app which allows access to IndexedDB again.

I have updated to iOS 14 beta 5 to see if I can reproduce the error on there but I now seem to get the "UnknownError: An internal error was encountered in the Indexed Database server" error again. Only encountered this after updating my web app using skipWaiting in the Service Worker. After the page reloaded, I could no longer access IndexedDB and eventually got the error message above. I have attached the com.apple.WebKit.Networking crash log.

Still trying to create a small repro. Once I can reproduce something I will post a link.

I've been unable to reproduce this  myself, but lots of other people do seem to have the issue:
https://github.com/johannesjo/super-productivity/labels/db

[David Gaynor]

Is this bug related: https://bugs.webkit.org/show_bug.cgi?id=216769? Should we track the patch listed there as the expected fix?

[Sihui Liu]

(In reply to David Gaynor from comment #43)
> Is this bug related: https://bugs.webkit.org/show_bug.cgi?id=216769? Should
> we track the patch listed there as the expected fix?

No this bugs should is not related. If you are seeing "An internal error was encountered in the Indexed Database server", it's very likely that WebKit process crahses (may or may not due to IndexedDB). Please check and attach com.apple.WebKit.Networking crash files if there is any (on iOS, go to Settings > Privacy > Analytics > Analytics Data). 

We keep fixing networking process crashes, so it would be nice if you can try on a latest OS build. It's also useful if you can provide steps to reproduce (with your test app, web page, etc) on an older build.

[Lee Robertson]

This is still an issue

[zac spitzer]

Lee, with which version are you seeing this error? the latest release?

[Lee Robertson]

I was able to reproduce on and ipad using version 13.4.1, but we have user's report it on version 14+

[Lee Robertson]

(In reply to zac spitzer from comment #46)
> Lee, with which version are you seeing this error? the latest release?


I was able to reproduce on an ipad using version 13.4.1, but we have user's report it on version 14+.

I will say it took a lot of effort to get this to occur. The error occurs when I try to delete a database that is used to store attachments (images, files, etc..).

[Valentin Funk]

I have just received this error in our Bugtracking tool for iOS Mobile Safari 14.0.3 using the popular idb and idb-keyval libraries.

[Frank]

On iOS 14.4.2 with Safari 14.0.3 I am as well recieving the error "UnknownError: Connection to Indexed Database server lost. Refresh the page to try again.".
It's a wide spread error for our users and we require a fix urgently!

We are consuming within a Crodova environment and error is coming randomly. Sometimes it seems to appear more frequently if you put the app into the background and then back to foreground again. But this might also be a wrong observation.

With iOS first versions of iOS 14 this popped up already.

Are there any known workarounds?

[Tim]

Created attachment 426532 [details]
iOS_14_5_com.apple.WebKit.Networking-2021-04-15-121002.ips

I've attached further crash logs and hope that these will be sufficient to finally narrow down the bug.

[Tim]

Created attachment 426533 [details]
iOS_12_4_com.apple.WebKit.Networking-2021-04-13-110655.ips

[Alexey Proskuryakov]

*** Bug 224804 has been marked as a duplicate of this bug. ***

[Lincoln Baxter, III]

We are also seeing this error both on iOS 12.5.2 and also on 14.4.2:

https://sentry.io/share/issue/aee6bb3031b740db8a7ca6bcb68b6bf2/

94.44%	
iOS 12.5.2
26 minutes ago

5.56%	
iOS 14.4.2
2 hours ago

`Error: Uncaught (in promise): UnknownError: Connection to Indexed Database server lost. Refresh the page to try again`

[Lee Robertson]

Does anyone know if the new connection bug in 14.6 is related to this issue?

[Lee Robertson]

iOS Version 14.6:

I am able to reproduce the issue doing the following steps:

1. Save a couple times to IDB
2. Close the app (Return to home screen)
3. Do something in another App
4. Swipe up to show open processes
5. Open your web app again
6. (Repeat the above steps)

I usually get the error to happen after a couple times doing the above steps.

[Sigmund Hansen]

On one particular phone running iOS 16.4.1, we were seeing the "UnknownError: Connection to Indexed Database server lost. Refresh the page to try again." error. After getting access to the phone, I found there were JetsamEvent logs on it, and could see Low Memory warnings in Instruments' Activity Monitor. I'm guessing the SQLite/IndexedDB Process was chosen for eviction in this case. It was easy to reproduce, after performing about 20-50 transactions this would consistently occur.

After I deleted all locally stored data from Safari. The issue disappeared. There was only about 30 MB of locally stored data.

This particular phone was a tester's phone, which is only used for testing, so it doesn't have a lot of apps installed either.

We are going to try and reproduce it. And I'll upload some JetsamEvent logs for you to analyze as well.

[Amir Angel]

This is still a thing 2023 :( 
Anyone manage to fix this?

[Chris Dumez]

(In reply to Amir Angel from comment #58)
> This is still a thing 2023 :( 
> Anyone manage to fix this?

We're hoping https://bugs.webkit.org/show_bug.cgi?id=259078 will help (this fix is very recent and hasn't made it into the beta builds yet).

[Julian Dixon]

(In reply to Chris Dumez from comment #59)
> (In reply to Amir Angel from comment #58)
> > This is still a thing 2023 :( 
> > Anyone manage to fix this?
> 
> We're hoping https://bugs.webkit.org/show_bug.cgi?id=259078 will help (this
> fix is very recent and hasn't made it into the beta builds yet).

Any idea on a timeline until that fix goes into production?

[J. Van Boxtel]

(In reply to Chris Dumez from comment #59)
> (In reply to Amir Angel from comment #58)
> > This is still a thing 2023 :( 
> > Anyone manage to fix this?
> 
> We're hoping https://bugs.webkit.org/show_bug.cgi?id=259078 will help (this
> fix is very recent and hasn't made it into the beta builds yet).

Did this make it into iOS 16.7 or iOS 17?

[Piotr]

This is still happening on iOS 17.4 with "Connection to Indexed Database server lost. Refresh the page to try again".
So clearly we can't rely on indexeddb on iOS safari...

[Graphefruit]

Having the same issue.
The issue now came up with 17.4.X iOS Version.
I'm running on the IndexedDB solution since several years, but now the the iOS Version 17.4.X within one week I had about 10 users reporting about data loss, which I could track back that the IndexedDB could not be accessed, and therefore the data where gone when closing the application.

Any news and fixes on the horizon?

"Error: Uncaught (in promise): UnknownError: Connection to Indexed Database server lost. Refresh the page to try again"

Thanks

[Graphefruit]

Having the same issue.
The issue now came up with 17.4.X iOS Version.
I'm running on the IndexedDB solution since several years, but now the the iOS Version 17.4.X within one week I had about 10 users reporting about data loss, which I could track back that the IndexedDB could not be accessed, and therefore the data where gone when closing the application.

Any news and fixes on the horizon?

"Error: Uncaught (in promise): UnknownError: Connection to Indexed Database server lost. Refresh the page to try again"

Thanks

[Luke Abbott]

My Cordova-based iOS app started catching the same issue as Graphefruit and Piotr ever since the 17.4 release:

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

Hundreds of users (a good percentage of my user base) have seen this issue; it's been caught by Sentry over 3k times. Always iOS 17.4 or newer (including 17.5). 

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

[Sihui Liu]

This IndexedDB connection lost error is caused by WebKit network process crash, and we have fixed different kinds of crashes and made updates to IndexedDB implementation since the bug was filed in 2019. 

Despite these crashes lead to the same result (connection error), they have different causes and need separate investigation in different builds, i.e. the error appeared in iOS 17.4+ is much likely to have a different underlying cause than the error in 2019 or 2021 (since we've fixed the 0xdead10cc issue indicated in the attachments). Therefore, I am going to close this stale bug.

We are investigating error of iOS 17.4+ in https://bugs.webkit.org/show_bug.cgi?id=273827. Please update information and upload crash reports there.

[Josh Kelley]

(In reply to Daken Misen from comment #67)
> Review your code to ensure that IndexedDB operations are handled correctly.
> The error “Attempt to get a record from database without an in-progress
> transaction” suggests there might be issues with how transactions are
> managed in your app. Make sure that you are properly managing transactions
> and ensuring they are active when performing database operations.

I'm far from an expert on IndexedDB, so I could be misunderstanding, but I'm not certain that this is correct. If I deliberately mismanage my IndexedDB transactions in JavaScript, I get errors similar to the following:

> InvalidStateError: Failed to execute 'objectStore' on 'IDBTransaction': The transaction finished.

> TransactionInactiveError: Failed to execute 'get' on 'IDBObjectStore': The transaction is inactive or finished.

These errors have specific names (e.g., "InvalidStateError"), and they reference JavaScript method and class names, and the WebKit source code suggests (to me, as a developer unfamiliar with the codebase) that they're thrown by the C++ code that directly implements the JavaScript APIs.

By contrast, the "UnknownError: Attempt to get a record from the database without an in-progress transaction" is thrown at a lower level, by the internal IndexedDB server's SQLite backing store; it feels like it may be an internal WebKit bug (WebKit internally mismanaging its transactions) rather than a JS bug.

I could easily be misunderstanding, though.

[Luke Abbott]

(In reply to Daken Misen from comment #67)
> Review your code to ensure that IndexedDB operations are handled correctly.
> The error “Attempt to get a record from database without an in-progress
> transaction” suggests there might be issues with how transactions are
> managed in your app. Make sure that you are properly managing transactions
> and ensuring they are active when performing database operations.

The issue that I and many other developers are running into is caused by an iOS system issue introduced in 17.4, not any issues with JS code. Please see https://bugs.webkit.org/show_bug.cgi?id=273827, where this bug was discussed in greater detail.

[Alexey Proskuryakov]

Comment 67 from "Daken Misen" was spam (external link inconspicuously embedded), and it is now removed.

Same issue using Ionic/Capacitor/Firebase on iOS.