Open MattSkala opened 2 weeks ago
Hi @MattSkala, thank you for reporting this issue. Could you please enable debug level logging and see if it is possible to capture more info on the crash?
Hey @MattSkala. 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!
Could you please enable debug level logging and see if it is possible to capture more info on the crash?
Hi, as mentioned above, unfortunately, we are not able to reproduce the issue locally. We just get crash reports from a small percentage (but still a considerable amount) of our users.
I can just add that the Crashlytics issue ID cf4e5375be64dd352e247f10f18c271c, and our project number 499050530164, in case it helps in any way.
Hi @MattSkala, unfortunately, I cannot access the crashlytics log. And the log provided indicates that it is failing to write into firestore (handleRejectedWrite) due to permissions issue. So high likely, it failed at the "creating an account" stage, not "accessing user's document " stage later.
It will be more efficient if you can file a firebase support ticket, provide the Crashlytics issue ID, project Id, and if possible a timestamp when the issue happened, so that firebase team/ backend team can get a closer look at the server logs.
Out of curiosity, what is the security rule the project is using?
So high likely, it failed at the "creating an account" stage, not "accessing user's document " stage later.
I just checked that all the Crashlytics logs have the ID of the authenticated user attached, so it seems that the account was created successfully, but then it failed when writing the user document.
It will be more efficient if you can file a firebase support ticket, provide the Crashlytics issue ID, project Id, and if possible a timestamp when the issue happened, so that firebase team/ backend team can get a closer look at the server logs.
Thanks for the suggestion, I've also created a support ticket (Case 10321781).
Out of curiosity, what is the security rule the project is using?
We only allow the authenticated user to read their own document:
match /users/{user_id} {
allow read, write: if request.auth.uid == user_id;
}
interesting, would it be possible to check "request.auth.uid == user_id" condition before sending the request? could it be one of the id is still null when the request is made?
[REQUIRED] Step 2: Describe your environment
[REQUIRED] Step 3: Describe the problem
Steps to reproduce:
We are seeing some users experiencing a crash with "io.grpc.StatusException - PERMISSION_DENIED: Missing or insufficient permissions." in Crashlytics. The full stack trace is pasted below.
We've been seeing this over the past few months over several Firebase SDK versions. It happens quite rarely and we are not able to reproduce it. It seems the exception is thrown in the Firestore background service, so we are not able to locate our code that could trigger this and there is no way to catch the exception.
Based on the analytics logs it seems to happen when we access the user's document in Firestore shortly after creating an account. On the first sigh it looks like a race condition between Firebase Auth and Firestore, but it doesn't seem to be on our side as we wait for
FirebaseAuth.signInWithCredential
task to complete orAuthStateListener
to trigger before calling any Firestore methods.