FIRESTORE (10.12.0) INTERNAL ASSERTION FAILED: Unexpected state #8250
Comments
luke-rogers
added
new
jbalidiong
added
needs-attention
and removed
new
|
Looking into the Firebase logs, the error seems to occur after Our app uses I wonder if there would be any legs in not having a tab manager if that will result in no calls to This is also similar to what is described by another GitHub user here I don't know a lot about the internals of the tab management so might be completely wrong here. Sample Log @wu-hui I would be Happy to share the full log with you privately if you could let me know the best way to do that. |
|
This has gotten really bad for us over the past few days. We didn't deploy anything. 
Edit: This is on desktop. |
|
@vojto Perhaps that's a different issue, this has always been limited to just iOS for us. |
|
I think the multitab log might be unrelated, this seems to stem from a underlying webchannal message. |
|
Fair enough, not an area I've dug too deep into. @wu-hui what steps can I take to help try and move this forward? |
|
Still seeing this issue on the latest version. I have logs I can share if that would be useful? |
|
@luke-rogers I would like to review the logs. You can share the logs through a private GitHub repo (shared with me), through a Cloud support ticket, or through a Firebase support ticket. If creating a ticket with either Google support channel, please reference this GitHub issue so the support staff knows to route the ticket to my team. Thanks! |
|
I encounter the same problem. Usually this is combined with
The problem is always resolved by loggin out (clearing local storage). EDIT: I created a new issue, as I am not sure if the underlying problem is the same. |
|
@MarkDuckworth I've shared the logs through a Firebase support ticket and via a private repo Let me know if you need anything more from me. |
|
@MarkDuckworth did you get access to the logs? Support said they forwarded them on. |
|
@luke-rogers, I received the logs. Thank you for sharing. On initial review, I don't see an obvious cause, but we will give it some deeper investigation as soon as we can. I've also started work on a PR to help us get error codes from these internal assertion failed messages. Do you also have a reproducible example that you can share with us? |
|
@MarkDuckworth Thanks for the update. PR looks good. Hopefully, you will be able to merge that. We would be happy to test a pre-release version of this if that would still be helpful? Unfortunately, we do not have a way of reproducing this ourselves at the minute. I have added some links to stack traces from Sentry to the readme of private repo I shared with you. |
|
@luke-rogers Mark is out of office and asked I take a look at logs. Could you grant access to private repo, to myself @tom-andersen and maybe some other members of our team such as @wu-hui ? Thanks. |
|
@tom-andersen added yourself and @wu-hui to the repo. Still struggling with a reproduction but if there is anything else I can try and help with please let me know. |
|
Update: The error with text The workaround might be to enable multi-tab support, since Firestore SDK will then handle this error by entering a non-primary role until IndexedDB resolves the problem, instead of treating this like a fatal error. That this happens at all, is a little concerning, and might have more to do with the AppleWebKit. |
|
@luke-rogers Are you able to enable multi-tab and see if that resolves the problem? |
|
@tom-andersen we will enable multi-tab and report back. Hopefully doing a release today so should have some initial feedback by the end of the week. |
|
Hey @luke-rogers. We need more information to resolve this issue but there hasn't been an update in 5 weekdays. I'm marking the issue as stale and if there are no new updates in the next 5 days I will close it automatically. If you have more information that will help us get to the bottom of this, just add a comment! |
|
We released yesterday with the change to enable multi-tab. We will have more of an update within the next few days as to whether it's made a difference. |
|
Unfortunately enabling multi-tab has not resolved this issue. I am still trying to access the impact on the end user experience but we have managed to capture some logs for the error. I've added those to the GitHub repo previously shared. The new log files for this error with Firebase version 10.12.4 and multi-tab enabled are: |
|
Added an additional log file for Firebase version 10.12.5: 2024-8-12_12-53-14.log |
|
Just wanted to chime in and mention that we also started seeing the same error in our Capacitor app, running on Android. One notable change we did that started showing this error is when we introduced Some details:
|
|
Hi, sorry about the English, it's not my mother tongue I was getting the error “@firebase/firestore: Firestore (10.13.0): FIRESTORE (10.13.0) INTERNAL ASSERTION FAILED: Unexpected state”, when I went to investigate I saw that the cause would be the error ‘ERR_BUFFER_OUT_OF_BOUNDS’, what helped me to solve this error was this article in Stackoverflow, I downgraded nodejs from version 22.7.0 to 22.5.0 and it solved my problem, I hope it helps someone. |
|
I my particular case the solution was to downgrade to the version |
|
I want to add on an interesting observation, since I've seen a few issues pop up relating to Capacitor which means it's a mobile app. My friend was able to coincidentally reproduce it where he had a very bad internet connection. And he saw our handled Firestore errors, but Sentry reported them as ASSERTION FAILED. Interesting .... |
|
@luke-rogers @vojto curious if you've been able to fix this or find out the cause of it? These errors are plaguing our Sentry from our Capacitor app. |
|
@anderecc would it work with nodejs v20.11.0? I see some of my users getting FIRESTORE (10.12.4) INTERNAL ASSERTION FAILED: Unexpected state |
|
@shaffy9633, Hello, I believe it will work, I'm using nodejs 22.9.0 and firestore 10.13.0 and not having any problems at the moment related to this 'error', try updating firestore |
|
I have a similar issue (#8383) and tried to implement the new version of the sdk released yesterday, |
|
We are experiencing similar issues on several devices and it looks we were able to find the cause of this error (at least in our case): Short timeline:
All devices with this error have a high number of It's also in line with the error message we see during / around the time of our config: most devices are running on iOS |
|
To validate if you guys have similar issues, run this script in the console: This will output the size of each object store, including the
|
|
Still getting a very large number of reports for this issue. Added an additional log file for Firebase version 10.14.1: 2024-12-11_10-28-1.log |
|
@luke-rogers The link you posted does not work for me. |
|
@wu-hui I've just invited you to the repository. |
|
I can see the logs now, thanks. Sorry if it is buried in the thread: are you able to reproduce this yourself? If so, can you share a minimum reproduction? OTOH, I believe this is the outcome of https://bugs.webkit.org/show_bug.cgi?id=202705 It was reported before #2232 and we made a change to make the error less frequent (#2307). The root cause is still there however. To properly fix this we might need to reconsider how the SDK interacts with indexeddb, and this is going to be a pretty big change that we do not have a timeline for. We can update here once we have a decision on what to do. For googlers only: b/387310299 |
|
Unfortunately, we've never found a way to reproduce these errors ourselves. The best I've got is the Firebase debug logs in the repository I added you to. There seem to be several combinations of the We're seeing thousands of these errors per week across our customers though so it's certainly prevalent. |
|
Hi Luke, I understand this is worrying. Unfortunately it might be out of what we can do to completely fix this issue. We will discuss internally to see if we can reduce the frequency this happens. We are also under capacity constraints recently, so whatever we decided to do, it might take some time. Sorry for the inconvenience. |
|
Hello, @luke-rogers We have spent the past few months fire fighting this on and off with our app and have finally got it to the point where we have a repeatable easy to recreate (for us) test case. Can confirm is connected to enable/disabling persistence. We noticed it happened much more often for slow/unstable internet connected devices. In our test case the best way to reproduce was to;
Once this occurs only a window.reload() will get firebase errors to stop. @wu-hui - Do you and the team already have enough information from what @luke-rogers has provided to investigate or would it be helpful if we produced a Minimal Reproducible Example also? |
Thank you! Downgrading worked for me. This should be emphasized as the best current workaround. I'll look forward to the actual fix. Best of luck! |
Oops, nevermind... |
Operating System
iOS 17.4.1
Browser Version
Mobile Safari UI/WKWebView (AppleWebKit/605.1.15)
Firebase SDK Version
10.12.0
Firebase SDK Product:
Firestore
Describe your project's tooling
Angular web app running on iOS via Capacitor
Firestore offline persistence enabled with unlimited cache size
Describe the problem
For a long time now we have been plagued by this iOS-only issue and have received many reports from users that it's causing the app to stop working and forcing them to restart.
We have captured some Firebase debug logs of this error which I am happy to share privately.
This seems similar to the following issues:
Example Errors
Example Stack Trace
Steps and code to reproduce issue
Steps currently unknown but possibly related to the app going between the background and the foreground over time.
The text was updated successfully, but these errors were encountered: