-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Empty orderBy field path when retrieving cached query from LevelDB #6721
Comments
We've encountered the same issue. The full stack trace is pretty much the same: The unfortunate part is, when this bug appears, it would consistently crashing our App until the user re-installed the App. Xcode version: 12.0 Full stacktrace:
|
Hi @dconeybe did you have the Chance to explore this issue? I available if you need more data or context. Thanks |
Sorry for the slow updates here. @canyousayyes or @gautier-gdx - Can you let me know if you use |
@schmidt-sebastian We do not use any Also for your reference, we have enabled persistence in Firestore, and use the default cache size (10MB). I am not familiar with the internal structure of Firebase SDK, but looking into the code of
For some reasons if the Any chance that a checking can be added into the BTW, when the Firestore is running GC, I did not see any of the logs printed even if I set |
@gautier-gdx @schmidt-sebastian May I also ask the consequences of disabling the garbage collection entirely? Does it mean:
Given that we saw quite a few users are hitting this crash, we would like to have a workaround soon ... |
@schmidt-sebastian We do not use @canyousayyes I can't tell you but if 2. is true then I personally have a lot of users crashing for not having enough space left on device because of persistence (see #6727). So I would not advice using |
@canyousayyes If I will continue to look at this and update this issue as we come up with a fix. If this specific decoding issue is the only issue that causes trouble, then we can certainly look at ignoring this specific failure. |
@schmidt-sebastian Thanks! Please keep us posted. For the I wonder if it's possible to check whether there's pending writes / un-synced data in client side, or just clean the cache storage? |
In the meantime, I will do more investigation here. |
Unfortunately, we haven't been able to determine a root cause given the information that is exposed by the stacktrace. We will add more logging in the next release (which really means "next next" since we just cut a release). |
@schmidt-sebastian Thanks for the update. For the more logging part, does it mean we have to upgrade our SDK to the new version (when it's released), wait until we have users who hit the same crash, then report here with the new stacktrace / logs so that you can continue the investigation? |
@canyousayyes Those are the steps. Unfortunately, I was not able to figure out the root cause based on the current stack trace. |
@schmidt-sebastian thanks to the new update I was able to get more infos from our crashes, here's the full stack trace:
NB: this crashes is only an example out of all our different queries, but we get the same crashes from different queries from various collections |
Reformatted, that looks like this:
|
It looks like your query has at least this much in it: let minDate = Timestamp(seconds: 1605285000, nanoseconds: 766999000);
db.collection("messages")
.where("compositeIndex", isEqualTo: "BET1bJITtNfxlQ5mm6sf9Hw9PJG3_zg7FgxLJ2fMAX0WedVf58dX9Ce52")
.where("creationDate", isGreaterThan: minDate)
.limit(20) Is there a query like this in your code and are there any other filter/orderBy statements on it? |
Hi, @wilhuff, thanks for the quick reply. This query is used with a snapshot listener only, and other queries which have the same type of crash are too. so it might come from that. I believe from query used to get the document from the cache Another hint is that queries who are crashing are always orderer with a Firestore Timestamp property, so maybe it's related to the way you retrieving the Timestamp ? I'm only guessing here |
Wait, are you sure there's no orderBy? Something like db.collection("messages")
.where("compositeIndex", isEqualTo: x)
.where("creationDate", isGreaterThan: y)
.orderBy("creationDate", descending: true)
.limit(20) |
Yes excuse me, there is always the same |
@wilhuff do you have any update on this issue? It's still the biggest crash in our app, impacting more than 1% of our user base (50k DAU). And as @canyousayyes said before, it's a nasty one since once a user gets it he will have it indefinitely until he downloads the app again. If you need further informations I'm here to help. |
We will likely change the garbage collector to skip over targets it cannot serialize, which should alleviate this crash. |
@schmidt-sebastian Thanks for the fix! Any plans to make a new release to include this fix at this moment? |
@canyousayyes I updated the milestone on this issue. It's scheduled for the upcoming 7.3.0 release targeted for next week. |
[REQUIRED] Step 1: Describe your environment
Xcode version: 12.0.1
Firebase SDK version: 6.34.0
Firebase Component: Firestore
Component version: 6.34.0
Installation method: CocoaPods
[REQUIRED] Step 2: Describe the problem
We had a lot of crash recently with the following error:
FIRESTORE INTERNAL ASSERTION FAILED: Invalid field path (). Paths must not be empty, begin with '.', end with '.', or contain '..' (expected !segment.empty())
After inspecting the code and the stack trace, it's seems that this crash is coming from an assertion when trying to retrieve a query from the levelDB caches specifically on a orderBy. because it's coming from the
FromServerFormatView
, we don't have any crashes coming fromFromDotSeparatedStringView
so it's not directly related to our codebaseBecause all the
FIRESTORE INTERNAL ASSERTION FAILED
are grouped in one single crash in Crashlytics I can't really tell you how much it's impacting our app but it's one of the biggest redundancies.Here is the full stack trace:
The text was updated successfully, but these errors were encountered: