Firebase-js-sdk: IOS 12.2 - Safari 12.1 - INTERNAL UNHANDLED ERROR: ... error ... Indexed Database server

[Frou-HOS]

My environment

• Operating System version: IOS 12.2
• Browser version: Mobile Safari 12.1
• Firebase SDK version: 5.9.3
• Firebase Product: Firestore
• JS Framework: Vue.js

The problem

This problem comming with the IOS 12.2 update.
Every time i send my App to the background, launch an other app and come back to my app, my app freeze due to this error :

• @firebase/firestore: Firestore (5.5.0): INTERNAL UNHANDLED ERROR: An internal error was encountered in the Indexed Database server

When i disable persitence it seems to be working but it's really slow.
An other error throw after for each action :

• AsyncQueue is already failed: An internal error was encountered in the Indexed Database server

Sentry issue :
https://sentry.io/share/issue/e4a452668dd54497b20c20d720a0aa3e/

Steps to reproduce:

Have a snapshot on collection on your app and enable persistence on
IOS 12.2
Mobile Safari 12.1
Kill all your app
Launch your app -> make some action calling snapshot
Back IOS Home
Launch an other app (ex: twitter)
Back IOS Home
Lanch your app -> error throw

[JeffAtGoog]

Hi Frou-HOS - I was wondering if you might be able to provide some more information to help us reproduce the issue. I have attempted but have been unsuccessful in reproducing the issue you have reported above.

My setup:

• iPhone XS 64 GB
• iOS 12.2 / Safari 12.1
• Firebase SDK 5.9.0
• Simple application that creates a snapshot to a document (also tried to an entire collection)

I followed your steps:

1. Kill all running applications
2. Launch My Application and trigger the snapshot
3. Put application into background
4. Launch Twitter (+ many other applications)
5. Back to iOS home screen
6. Open My Application again

Based on this I was wondering if you may be able to share with us more details on how you are able to reproduce the issue.

If possible please provide the device you are using, how you are establishing the snapshots, how much storage space is free on the device, and if there is anything happening when your application sleeps/resumes.

It would be greatly appreciated if you could create a MVCE (https://stackoverflow.com/help/mcve) for this.

Thanks,
Jeff

[jbgomez21]

I have exactly the same problem.
Until now only iOS 12.2.
The problem is with enablePersistence, if it's enable fail approx 50% times

In my case:

this.afAuth.auth.signInAndRetrieveDataWithCredential(facebookCredential).then(userCredential => {
       console.log('It's OK!');
      return userCredential.user;
      });
    }).catch(error => {
      console.log(error);
       return null;
    });

signInAndRetrieveDataWithCredential sometimes works fine sometimes return the error

{ "message": "Failed to execute 'transaction' on 'IDBDatabase': The database connection is closing.", "code": 11}

[Frou-HOS]

Thanks @JeffAtGoog for your feedback and your test
For me the issue seems to be present on each device with the ios 12.2 update, devices tested:

• ipad mini 2
• ipad pro 2019
• iphone X

So like you suggest I made a MVCE who give me the same error result avaible here :
https://test-a77b5.firebaseapp.com/restaurant
You can click on "evening" or "morning" for load sucollection snapshot
Step to reproduce :

• kill all app
• open link on safari mobile 12.1
• back on home
• open over app
• back home
• reopen our app by screen app launched (a little refresh of the app appear normaly) and the app freeze you cannot recall a snapshot when you click on "morning" or "evening" text

you can found the source code of this MVCE app here :
https://gitlab.com/alex.frou/mvce-ios-12-2-bug.git

This exemple didn't contain authentification like say @jbgomez21 i think it's the enablepersistance in cause, i read some article say IOS 12.2 made some modifications on data persitence and persitence seems buggy

[JeffAtGoog]

Hello @Frou-HOS - Really appreciate your assistance and taking the time to produce the MVCE for us.

I wanted to quickly follow up as I have been following your instructions to reproduce the error but seem to be unable to trigger it.

My Setup:

• iPhone XS 64 GB
• iOS 12.2 / Safari 12.1

My exact steps:

• Kill all running apps on my phone
• Open Safari to page https://test-a77b5.firebaseapp.com/restaurant ( I had this page previously loaded and I am not typing the URL into Safari)
• Open Safari Developer console on my Macbook to monitor console logs messages (I have Web Inspector enabled for mobile Safari | Settings -> Safari -> Advanced -> Web Inspector )
• Go back to home screen
• Launch a different application (Twitter, Netflix, etc)
• Go back to home screen
• Reopen Safari - opens directly to https://test-a77b5.firebaseapp.com/restaurant
• Click between morning / evening and see everything working

Based on this I am wondering:

• Can you see anything that I am doing different than what you are doing?
• Do you have multiple tabs open in Safari? I closed all other tabs before starting my test.
• If possible share how much data your test app is consuming in Safari ( Settings -> Safari -> Advanced -> Website Data )

[Frou-HOS]

Hello @JeffAtGoog ,
I made a little video to show you how i reproduce ce bug on my ipad :
https://youtu.be/PBUGiIinRBA
_sorry for my french accent and my basic english_

About your questions :

• Can you see anything that I am doing different than what you are doing? -> hope vidéo help
• Do you have multiple tabs open in Safari? I closed all other tabs before starting my test. -> nope
• If possible share how much data your test app is consuming in Safari ( Settings -> Safari -> Advanced -> Website Data ) -> 2,5 Mo

[drahuks]

Hello guys,

If it can be of any help, I am facing the same issue on an ionic application running firebase 5.9.4, with persistence enabled

The issue : FIRESTORE (5.9.4) INTERNAL ASSERTION FAILED: AsyncQueue is already failed: An internal error was encountered in the Indexed Database server

It happens when app is put in background for a moment, but not easy to reproduce. But it also happens when using ionic native camera plugin (@ionic-native/camera). calling camera.getPicture() with sourceType = PictureSourceType.CAMERA

Here is a link to a Sentry report : https://sentry.io/share/issue/1001cca80b914f2188f899ac34d5f6c4/

[CaptainCodeman]

Same issue here - iOS + enablePersistence = sporadic errors with firestore. These are devices that are just left running, not suspended, no app switching. Periodically they just stop talking to firestore.

With persistence disabled everything works fine.

[schmidt-sebastian]

Hey all! As this is sounding more and more like an issue in Safari on iOS 12, I have filed an issue with the WebKit team: https://bugs.webkit.org/show_bug.cgi?id=197050

In the meantime, if we can narrow down the root cause, we might be able to work around this. Other reports of similar issues point to users storing UInt8Arrays in Object Stores with auto-incrementing keys. While we do use auto-incrementing keys, we do not store UInt8Arrays in IndexedDb. This unfortunately means that it is hard to fully understand the scope of this problem.

[jggc]

If it can help here is my relatively reliable reproduction setup :

const makeTestDoc = (id) =>
  firestore.collection('test').doc(id).set({ foo: 'bar', date: Date.now(), cordova: isCordovaEnvironment() })
    .then(() => { console.log(`Doc ${id} completed`); })
    .catch((e) => { console.log(`Doc ${id} failed`, e); });

window.testFirestore = async () => {
  for (let i = 0; i < 30; i += 1) {
    const promises = [];
    promises.push(makeTestDoc('paul1'));
    promises.push(makeTestDoc('paul2'));
    promises.push(makeTestDoc('paul3'));
    promises.push(makeTestDoc('paul4'));
    promises.push(makeTestDoc('paul5'));
    await Promise.all(promises);
  }
};

This is running in a cordova application with enablePersistence.

• Deploy this to a physical device (iPhone 7 in my case)
• Open safari debugger
• Launch testFirestore()
• Put the app in background while it is writing a batch of pauls
• Kill/Open some heavy apps. Just switching to an already open app did not seem to do it, the apps had to be killed and relaunched, except the tested app of course.
  - We've had Pokemon Go cause memory issues on some devices in the past so this is my "heavy app" with a few other random apps
• Come back to the app writing pauls
• If not on the few try of background -> heavy app -> come back, after a few times you should get an INTERNAL_UNHANDLED_ERROR

Here is the first few error logs I get from firestore :

[Error] [2019-04-18T17:04:11.889Z]  @firebase/firestore: – "Firestore (5.8.0): INTERNAL UNHANDLED ERROR: " – "An internal error was encountered in the Indexed Database server"
    (anonymous function) (cordova.js:1732)
    a (vendors.0e139c06.chunk.js:1:1923613)
    error (vendors.0e139c06.chunk.js:1:1925005)
    v (vendors.0e139c06.chunk.js:1:1926263)
    (anonymous function) (vendors.0e139c06.chunk.js:1:2022452)
    promiseReactionJob
[Error] [2019-04-18T17:04:12.392Z]  @firebase/firestore: – "Firestore (5.8.0): SimpleDb" – "IDBDatabase onerror called" – "firestore/[DEFAULT]/medyx-ci/main" – "{\"isTrusted\":true}"
    (anonymous function) (cordova.js:1732)
    a (vendors.0e139c06.chunk.js:1:1923613)
    error (vendors.0e139c06.chunk.js:1:1925005)
    v (vendors.0e139c06.chunk.js:1:1926263)
    onerror (vendors.0e139c06.chunk.js:1:2029502)
[Error] [2019-04-18T17:04:12.393Z]  @firebase/firestore: – "Firestore (5.8.0): SimpleDb" – "IDBDatabase onerror called" – "firestore/[DEFAULT]/medyx-ci/main" – "{\"isTrusted\":true}"
    (anonymous function) (cordova.js:1732)
    a (vendors.0e139c06.chunk.js:1:1923613)
    error (vendors.0e139c06.chunk.js:1:1925005)
    v (vendors.0e139c06.chunk.js:1:1926263)
    onerror (vendors.0e139c06.chunk.js:1:2029502)
[Error] Failed to load resource: WebKit encountered an internal error (channel, line 0)
TypeError: WebKit encountered an internal error
    (anonymous function) (cordova.js:1732)
    We (main.19cb17e9.chunk.js:1:1195658)
    (anonymous function) (main.19cb17e9.chunk.js:1:1194316)
    promiseReactionJob
[Error] Failed to load resource: WebKit encountered an internal error (channel, line 0)
[Error] UnknownError: An internal error was encountered in the Indexed Database server
    (anonymous function) (vendors.0e139c06.chunk.js:1:2022561)
[Error] Unhandled Promise Rejection: InvalidStateError: Failed to execute 'abort' on 'IDBTransaction': The transaction is inactive or finished.
    abort (vendors.0e139c06.chunk.js:1:2033358)
    abort (vendors.0e139c06.chunk.js:1:2033358)
    (anonymous function) (vendors.0e139c06.chunk.js:1:2031857)
    wrapUserFunction (vendors.0e139c06.chunk.js:1:2028099)
    catchCallback (vendors.0e139c06.chunk.js:1:2027935)
    (anonymous function) (vendors.0e139c06.chunk.js:1:2027504)
    wrapUserFunction (vendors.0e139c06.chunk.js:1:2028099)
    catchCallback (vendors.0e139c06.chunk.js:1:2027945)
    (anonymous function) (vendors.0e139c06.chunk.js:1:2027504)
    wrapUserFunction (vendors.0e139c06.chunk.js:1:2028099)
    catchCallback (vendors.0e139c06.chunk.js:1:2027945)
    (anonymous function) (vendors.0e139c06.chunk.js:1:2027504)
    wrapUserFunction (vendors.0e139c06.chunk.js:1:2028099)
    catchCallback (vendors.0e139c06.chunk.js:1:2027945)
    (anonymous function) (vendors.0e139c06.chunk.js:1:2027504)
    wrapUserFunction (vendors.0e139c06.chunk.js:1:2028099)
    catchCallback (vendors.0e139c06.chunk.js:1:2027945)
    (anonymous function) (vendors.0e139c06.chunk.js:1:2027504)
    onerror (vendors.0e139c06.chunk.js:1:2035874)
[Error] Unhandled Promise Rejection: UnknownError: An internal error was encountered in the Indexed Database server
    (anonymous function)
    promiseReactionJob

The IDBDatabase onerror called log comes from our firebase-js-sdk fork

https://github.com/jggc/firebase-js-sdk/blob/addingLogsAroundAsyncQueue/packages/firestore/src/local/simple_db.ts#L107

in the indexedDB.onerror handler. Which proves that this is something firestore cannot completely fix on its own. Hopefully someone will find a workaround but simply retrying the transactions won't do it as Safari seems to reject anything trying to interact with indexedDB once the bug happened.

I tried to establish a new indexedDB connection to a test database with this line but could not get the IDBOpenRequest to complete once the bug has happened even though it works fine on a fresh app start.
`r = indexedDB.open('test'); r.onsuccess = () => {window.testdb = r.result; console.log('success')}; r.onupgradeneeded = (up) => { console.log('upgradeneeded', up) }``

Lastly (a bit of a shameless plug for those on cordova), we have decided to move away from the javascript SDK on ios and worked on a fork of a cordova firestore plugin which is pretty much a drop-in replacement for the javascript sdk now. I couldn't reproduce the bug when using this plugin. It currently involves a bit of work to get it to work but if anyone is interested in using it I could soften a few rough edges. On Android and Web the Firebase Javascript SDK works just fine though.

[drahuks]

@jggc I am definitely interested in this fork. We have a Cordova/ionic app that highly relies on offline persistence. App is running on production for a few months now and I have to deal with all ios users having an app that freezes. My customer is really unhappy with that... So any alternative while waiting for a fix is good to me. Feel free to share some info about that and how to integrate this plug-in. Thanks in advance!

[jggc]

@drahuks We were exactly in this frustrated customer situation from November until this new release we made yesterday. It's still to early to tell if other issues will come up but its promising for sure.

I started an issue to document my process in my fork. Let's continue this conversation there to avoid polluting this thread any more. https://github.com/jggc/cordova-plugin-firestore/issues/1

[tgangso]

Alot of my users also has this issue, hope it can be prioritized. Seems to happend when the PWA has been left inactive for a while, or in the backround, or a tab in Safari that has been inactive. It locks the app and the user has to kill it and open it again. The issue seems to have increased dramatically with iOS 12.2.

Using enablePersistence with @angular/fire

[schmidt-sebastian]

If one of you is able to disable Garbage Collection and let us know if you still see the same error, that would help us a lot. The setting is here: https://firebase.google.com/docs/reference/js/firebase.firestore.Settings.html#cachesizebytes

Invoked as such:

firestore.settings({ cacheSizeBytes: firebase.firestore.CACHE_SIZE_UNLIMITED });

[tgangso]

I have had this issue before I upgraded from firebase 5.3.1 directly to 5.10.0 just a few days ago, and I believe the garbage collection was implemented in 5.7.0?

Issue was seen on Sentry before the upgrade, but it has spiked (2-3x the amount of events) in frequency after the upgrade, so I guess it could be related.

I also enabled experimentalTabSynchronization when i did this upgrade.

[drahuks]

Hello,

I have tried to disable cache (I'm using @angular/fire) with following code

constructor(private afs: AngularFirestore) { afs.firestore.settings({ cacheSizeBytes: -1 , }); afs.firestore.enablePersistence({experimentalTabSynchronization: true}); console.log('Firebase offline mode enabled'); }

Unfortunately the issue still occurs.

[driiftkiing]

Same here...
Also possible to reproduce it, when opening In-App-Browser or In-App-Camera.

[bjcooper]

We started seeing a very similar issue on April 14—maybe that reflects an iOS update release date or something, I don't know. I have been completely unsuccessful in reproducing it at my desk. Our analytics show that only iOS clients in the wild have experienced the issue so far (unlike https://github.com/firebase/firebase-js-sdk/issues/1642, which seems similar but affects Android).

The message is slightly different than the OP's, perhaps because of the Firestore lib version:

Error: FIRESTORE (5.9.4) INTERNAL ASSERTION FAILED: AsyncQueue is already failed: An internal error was encountered in the Indexed Database server

The error is sometimes, but not always, accompanied by this one around the same time:

UnknownError: An internal error was encountered in the Indexed Database server

This is from a Vue.js PWA with persistence enabled. I have seen it happen once, and the user opened the app, navigated around inside normally, then saved a new Firestore doc with the app, all without every switching out of the app, locking the device, or leaving it inactive.

[cepm-nate]

I'm also using Vue.js PWA with persistence enabled (using localForage with IDB), yet this bug usually hits when trying to store an image file as a buffer into IDB (with GUID keys). Once the bug hits, all further attempts to interact with IDB result in the "Connection to Indexed Database Server Lost" error. https://github.com/dfahlander/Dexie.js/issues/832 and https://github.com/ionic-team/cordova-plugin-ionic-webview/issues/354 look like they might stem from the same webkit bug.

[mikelehen]

I managed to create a simple pure-IndexedDb repro and have added it to the webkit bug here: https://bugs.webkit.org/show_bug.cgi?id=197050#c4 As far as I can tell, the error is completely unrecoverable (IndexedDb can't continue to be used or be re-opened). So I think we may be stuck until Apple fixes this. 😦

[Frou-HOS]

Thanks @mikelehen & @schmidt-sebastian

@schmidt-sebastian I made a test with CACHE_SIZE_UNLIMITED but the problem remains present

So until Apple fixes this i will disable Persistence.
I have a question (maybe a stupid question) -> Will I consume more data reading when i disable persistence ? Or persistence it just used / affect offline mode ?

[tgangso]

Hope apple will prioritize this, I will look into disabling persistence for my iOS users also for the time being.

[mohshraim]

this bug exist on iOS 11 also
i opened bug report with apple developer for this from 12 months.. no reply for now :D

[schmidt-sebastian]

If you disable persistence, Firestore falls back to memory persistence. Memory persistence builds up an in-memory cache that serves your results. If you listen, unlisten and listen again to the same query, the Firestore client does not need to read the initial set of documents again. This is, however, only true until the user reloads the page or restarts your app. If you have an app that users frequently restart or you use FIrestore on a webpage that gets reloaded often (e.g. a user clicks on a link), then your document reads will likely go up without persistence.

Update: My colleague pointed out that the "listen, unlisten, listen" sequence described above will indeed cause new reads on the backend since memory persistence very aggressively garbage collects data that is no longer referenced.

One caveat is that if you are building an app that only gets used a few times a day, with gaps of over 30 minutes in between, then disabling persistence will likely not have such a huge effect on the number of document reads (see: https://firebase.google.com/docs/firestore/pricing#operations: "If the listener is disconnected for more than 30 minutes (for example, if the user goes offline), you will be charged for reads as if you had issued a brand-new query."). You will still see an increase in network usage though.

As for next steps, it might help if everyone here cc's themselves on https://bugs.webkit.org/show_bug.cgi?id=197050. Thanks!

[tgangso]

Have anyone checked if the issue is there on iOS 12.3 beta?

[mikelehen]

Good question! If somebody can try my repro (https://bugs.webkit.org/show_bug.cgi?id=197050#c4) on iOS 12.3 beta that would be extremely helpful.

[mikelehen]

FWIW I've attempted a couple workarounds which did not work. Has anybody been able to try on iOS 12.3 beta?

[tgangso]

FWIW, after disabling persistence for iOS users only, i do not see this in my sentry logging anymore.

[sengoontoh]

I've given up on using firestore persistence. It's just not ready for primetime and fixes are dependent on Chrome and Safari which is out of my control. I wish the Firebase team could make a workaround.

[wilhuff]

I wish we could work around this too :-(. Nothing we've tried works.

Our current plan is to blacklist devices that are known broken. Our resolution to this will be to blacklist iOS 12.2 in here:
https://github.com/firebase/firebase-js-sdk/blob/master/packages/firestore/src/local/simple_db.ts#L133

Feel free to contribute platforms you encounter that cause problems. Unfortunately, we can't test them all.

[sengoontoh]

Yeah, that is definitely not a good resolution as iOS 12.2 is used by more than 80% of my users.
I wonder how do folks like PouchDb handle this without much complaints.

[timbru31]

I could not reproduce this issue with the iOS 12.3 beta anymore - can anyone confirm this, too? @mikelehen

[AverageHelper]

I couldn't reproduce it at all on iOS 12.2 on my iPhone 5s, but that's likely because it's slow. My iPhone 7 had this problem, though.

At any rate, iOS 12.3 is out now, and I can't reproduce this anymore on my iPhone 7 with both @mikelehen's repo and our production app. 12.3 seems to have fixed it. More confirmation, please?

[baversjo]

@SparrowBlaze @timbru31 are you sure you're no longer having this issue on ios 12.3? That would of course be great, but, the developers at apple said the fix isn't live yet:
https://bugs.webkit.org/show_bug.cgi?id=197050#c4

And @sengoontoh FYI we PouchDB users are hurting too. Tried some cordova sqlite adapters but they have their own set of stability problems it seems after a few weeks of trying them (in production...).

[AverageHelper]

@baversjo I can confirm I haven't seen the bug in iOS 12.3. Either they accidentally fixed it, or accidentally worked around it. I've tried both of @mikelehen's repos with no sign of those numbers stopping, and my production app, so far as I can tell in my own testing sans analytics, is as smooth as ever.

😆 If this really isn't fixed, there must be some crazy placebo goin' on!

[MarkChrisLevy]

@SparrowBlaze @timbru31 @baversjo @mikelehen I can confirm the issue still exists 12.3. Maybe (but maybe) it happens not as often as it was in 12.2, but I can reproduce it by doing this:

• open app, do something...
• when app is in foreground, put phone to sleep (let the screen turn off)
• after few minutes wake up the phone, the app should be in foreground and the error of IndexedDb is thrown

@mikelehen I understand, that you want to disable IndexedDb for affected iOS versions, but please make it opt-in or opt-out. For my app offline is a must, so IndexedDb must be used. In my case the only fix of that error is to reload an app when the error of IndexedDb is raised and it is better to reload than not having offline functionality.

[timbru31]

Unfortunately we still see this error in our tracking although we couldn’t reproduce this issue yet :/

[mikelehen]

@MarkChrisLevy Thanks for the feedback. I'll discuss with the team about how to proceed wrt disabling on iOS 12.2. Out of curiosity, are you somehow detecting when this happens and refreshing? If so, how are you detecting it right now?

[MarkChrisLevy]

@mikelehen I listen for app resume/foreground event and when the app is resumed I try fetch dummy data from firestore - if IndexedDB is disconnected, then firestore raise an error which will be catched and processed - if the error is related to IndexedDB (INTERNAL ASSERTION FAILED: AsyncQueue is already failed...) then I reload webview. I also have a global error handler that checks for that kind of errors, however in most cases on resume listener will catch that error. It is not as bad as it sounds, surely it would be better not to reload, but... it is better than nothing and as I wrote, in my case offline is a must.

[utb2017]

I ran into this problem today with the Iphone. I reckon I will try to accomplish my goals with the realtime Database instead of firestore on this one. I am just trying to update a firestore user account by adding a image link. Works on my computer then fails on my phone. When I navigate back to the menu of our site. None of the firestore products will load. Error: FIRESTORE (5.11.0) INTERNAL ASSERTION FAILED: AsyncQueue is already failed: An internal error was encountered in the Indexed Database server.

Could we blacklist the persistence on specific firestore documents? Just a thought. The problem does resolve after a refresh.

[wilhuff]

Note that the realtime database has no offline persistence support in its web SDK. You can get equivalent functionality by just disabling persistence in Firestore.

[peterpeterparker]

I'm using @angular/fire and get the same error reported many times by Sentry

[2019-06-19T16:45:41.135Z] @firebase/firestore: Firestore (6.2.0): FIRESTORE (6.2.0) INTERNAL ASSERTION FAILED: AsyncQueue is already failed: An internal error was encountered in the Indexed Database server

iOS 12.3.1 / Mobile Safari UI/WKWebView

Also I use the persistence with the synchronized tabs:

AngularFirestoreModule.enablePersistence({synchronizeTabs: true})

[var-const]

@peterpeterparker Unfortunately, iOS 12.3 is still affected by the bug. Please see this SO link for a workaround.

(By the way, could you please check your log to see if it contains the SO link I mentioned? It should be easily searchable by using this string: IOS_INDEXEDDB_BUG1. It appears you are using the latest release, so you should be seeing that message; if not, we'd like to know.)

[peterpeterparker]

Thx @var-const for the feedback. I guess I have to remove the persistence then.

Yes I do see IOS_INDEXEDDB_BUG1, but Sentry is reporting it in a separate error. I receive more often the error I displayed above (INTERNAL ASSERTION FAILED) and sometimes I received this error

IOS_INDEXEDDB_BUG1: IndexedDb has thrown 'An internal error was encountered in the Indexed Database server'. This is likely due to an unavoidable bug in iOS.

[nVitius]

According to the webkit bug tracker, this was patched in iOS 13.
I am still seeing users run into this problem (perhaps even more often now) in iOS 13. Is anyone else able to verify that this issue persists?

EDIT - the error also appears to be more severe now. The users loses their authentication state and is logged out.

[Saturnyn]

@nVitius From what I've seen, the error disappears on iOS 13 but is replaced by a worse one :/
See https://github.com/firebase/firebase-js-sdk/issues/2232.

[Pitouli]

I have the same error under iOS 13 (including iOS 13.1.3).

If I open my PWA (which is Safari), and click a button to make a get(), it works.
If I close my PWA, reopen it, and click the same button, I have an error message.
If I kill my PWA in the « switching app panel », and reopen it, then it works again.

The message :
Error: FIRESTORE (7.2.1) INTERNAL ASSERTION FAILED: AsyncQueue is already failed: An internal error was encountered in the Indexed Database server

Before iOS 13, the PWA were not kept in memory for long, so you had a reload almost every time (and when you were killing the app, it was not killed. The lifecycle was completely independent).

Since iOS 13, it behaves almost like a real app: you can leave the app alone for a "long" time, and when you reopen it, it stayed where you were. But with this bug, it becomes an issue rather than an improvement... The only good news is that now you can kill the app soit reload when you reopen it.

[mikelehen]

Closing this issue since the original iOS 12.2 issue can't be fixed any more than we've done. The iOS 13 issue is tracked by https://github.com/firebase/firebase-js-sdk/issues/2232 which we've made a potential fix / workaround for in JS SDK 7.2.3.