IOS 12.2 - Safari 12.1 - INTERNAL UNHANDLED ERROR: ... error ... Indexed Database server #1670
Comments
Frou-HOS
changed the title
|
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:
I followed your steps:
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, |
|
I have exactly the same problem. In my case: signInAndRetrieveDataWithCredential sometimes works fine sometimes return the error
|
|
Thanks @JeffAtGoog for your feedback and your test
So like you suggest I made a MVCE who give me the same error result avaible here :
you can found the source code of this MVCE app here : 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 |
|
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:
My exact steps:
Based on this I am wondering:
|
|
Hello @JeffAtGoog , About your questions :
|
|
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/ |
|
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. |
|
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. |
|
If it can help here is my relatively reliable reproduction setup : This is running in a cordova application with enablePersistence.
Here is the first few error logs I get from firestore : The 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. 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. |
|
@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! |
|
@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. jggc/cordova-plugin-firestore#1 |
|
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 |
|
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: |
|
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. |
|
Hello, I have tried to disable cache (I'm using @angular/fire) with following code
Unfortunately the issue still occurs. |
|
Same here... |
|
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 #1642, which seems similar but affects Android). The message is slightly different than the OP's, perhaps because of the Firestore lib version:
The error is sometimes, but not always, accompanied by this one around the same time:
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. |
|
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. dexie/Dexie.js#832 and ionic-team/cordova-plugin-ionic-webview#354 look like they might stem from the same webkit bug. |
|
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. 😦 |
|
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. |
|
Hope apple will prioritize this, I will look into disabling persistence for my iOS users also for the time being. |
|
this bug exist on iOS 11 also |
|
If you disable persistence, Firestore falls back to memory persistence. Memory persistence builds up an in-memory cache that serves your results. 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! |
|
Have anyone checked if the issue is there on iOS 12.3 beta? |
|
FWIW, after disabling persistence for iOS users only, i do not see this in my sentry logging anymore. |
|
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. |
|
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: Feel free to contribute platforms you encounter that cause problems. Unfortunately, we can't test them all. |
|
Yeah, that is definitely not a good resolution as iOS 12.2 is used by more than 80% of my users. |
|
I could not reproduce this issue with the iOS 12.3 beta anymore - can anyone confirm this, too? @mikelehen |
|
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? |
|
@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: 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...). |
|
@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! |
|
@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:
@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. |
|
Unfortunately we still see this error in our tracking although we couldn’t reproduce this issue yet :/ |
|
@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? |
|
@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. |
|
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. Could we blacklist the persistence on specific firestore documents? Just a thought. The problem does resolve after a refresh. |
|
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. |
… by #1670. * On iOS 12.2 we proactively warn about the "internal error was encountered in Indexed Database Server" Bug. * When the bug is actually encountered on iOS >= 12.2 an < 13 we log a custom error message. Both log message and error link to https://stackoverflow.com/q/56496296/110915 which provides potential error handling / recovery example.
… by #1670. (#1854) * On iOS 12.2 we proactively warn about the "internal error was encountered in Indexed Database Server" Bug. * When the bug is actually encountered on iOS >= 12.2 an < 13 we log a custom error message. Both log message and error link to https://stackoverflow.com/q/56496296/110915 which provides potential error handling / recovery example.
|
I'm using
iOS 12.3.1 / Mobile Safari UI/WKWebView Also I use the persistence with the synchronized tabs: |
|
@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: |
|
Thx @var-const for the feedback. I guess I have to remove the persistence then. Yes I do see
|
|
According to the webkit bug tracker, this was patched in iOS 13. EDIT - the error also appears to be more severe now. The users loses their authentication state and is logged out. |
|
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. The message : 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. |
|
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 #2232 which we've made a potential fix / workaround for in JS SDK 7.2.3. |
and others
My environment
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 :
When i disable persitence it seems to be working but it's really slow.
An other error throw after for each action :
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
The text was updated successfully, but these errors were encountered: