1 errors occurred during unsubscription:1) Error: FIRESTORE (12.9.0) INTERNAL ASSERTION FAILED: Unexpected state (ID: b815)

[LanderBeeuwsaert]

Operating System

macOS and Windows

Environment (if applicable)

Chrome 144, macOS, Apple --- Chrome 144, Windows 10

Firebase SDK Version

12.9.0

Firebase SDK Product(s)

Auth, Firestore

Project Tooling

Angular v20 + Firebase

Detailed Problem Description

Crash happened 9 times over the last few months.
also happened on 12.6.0
full crash stacktrace from production:

Error: FIRESTORE (12.9.0) INTERNAL ASSERTION FAILED: Unexpected state (ID: b815) CONTEXT: {"Pc":"Error: FIRESTORE (12.9.0) INTERNAL ASSERTION FAILED: Unexpected state (ID: ca9) CONTEXT: {"ve":-1}\n at m4 (https://www.acro-companion.com/chunk-AXBE2DBN.js:58:11251)\n at nr (https://www.acro-companion.com/chunk-AXBE2DBN.js:58:11340)\n at kS.We (https://www.acro-companion.com/chunk-AXBE2DBN.js:61:5013)\n at https://www.acro-companion.com/chunk-AXBE2DBN.js:61:5446\n at Array.forEach ()\n at rk.forEachTarget (https://www.acro-companion.com/chunk-AXBE2DBN.js:61:5738)\n at rk.tt (https://www.acro-companion.com/chunk-AXBE2DBN.js:61:5339)\n at https://www.acro-companion.com/chunk-AXBE2DBN.js:67:2478\n at Generator.next ()\n at https://www.acro-companion.com/chunk-4ZXV5L7B.js:1:1748"} at m4 (https://www.acro-companion.com/chunk-AXBE2DBN.js:58:11251) at si (https://www.acro-companion.com/chunk-AXBE2DBN.js:58:11049) at YS.uc (https://www.acro-companion.com/chunk-AXBE2DBN.js:70:36849) at YS.enqueue (https://www.acro-companion.com/chunk-AXBE2DBN.js:70:36040) at YS.enqueueAndForget (https://www.acro-companion.com/chunk-AXBE2DBN.js:70:35782) at n.handleDelayElapsed (https://www.acro-companion.com/chunk-AXBE2DBN.js:67:6407) at https://www.acro-companion.com/chunk-AXBE2DBN.js:67:6165

we already reported similar crashes before:
#9172
#7590 (comment)
#8383

not sure it's the same one

Steps and code to reproduce issue

production bug experienced by users

[MarkDuckworth]

Internal assertion with id CA9 is something you've reported before. This one has had multiple root causes. I've had several reproductions provided to me over time and we've released fixes for at least 2. Unfortunately the issue still lingers for some users, like yourself. I believe there is a race condition in the logic where the sdk subscribes to a snapshot listener, I haven't been able to determine why that condition exists, partially because it's very hard to reproduce in a controlled environment. This issue is still in my queue. If you are able to find a reproduction that you can share, please do share.

[LanderBeeuwsaert]

Hi Mark,

Thank you for your answer.
Rolling back to 12.3.0 is not something I would like to do.
We have approximately +-4000 daily users, I don't want to take the risk to go back 6 minor versions and break things because of unexpected regressions.
This specific crash occurs every +-15 days, so it would take around +-45 days I would say to determine with confidence that the rollback worked; which would still not point clearly towards the root cause.

What we do in our project: crashes that can happen from multiple causes/parent functions; to give pass in the parent function a unique id and that gets passed to the function/code that is called by those.
That way it becomes possible to determine what was the initial calling function.

Another option we would be happy to help with, would be to have an option as client application that firebase should store a sort of rolling logging, and when a crash/error like this happens, that our client application can "request" the last 1000 lines of this internal/memory logging and we can log it out towards our logging.

START RANT
You'll see that we've been working with firebase/firestore for a long time:
#7590
#8886
#1674
#9172
#8383
(I'm only listing up the ones that are still ongoing, you can search my user tag to see I've been a pain in the *** since 2018)
And you as well indicate we've reported this issue before.
And while our application has grown, some of the issues we've reported have been addressed.
However, some have remained open over years.
With 4000 users daily, we're now experiencing between +-2 to +-10 errors daily because of firebase.
We've already invested in cutting out angularFire for obvious reasons, but we are also trying to find investment into switching away from firebase.
One of the reasons is because we want more sql-like capabilities, but strong second place is that we know that as long as we stay with firebase our users will continue to have crashes.

Anyway, I understand that there are other priorities that a team has to juggle.
I hope the firebase team can find a way to invest time in solving this and make it easier to solve similar issues in the future
The ids you guys added were already a step in the right direction; on the other hand, whoever took the initial decision to strip out all error messages and make errors not uniquely identifiably…… tsssss….
END RANT ---

Apologies for the above, I hope you can understand our position.