-
Notifications
You must be signed in to change notification settings - Fork 893
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
randomly freezes for 45 seconds when getDocs after update transaction #8474
Comments
I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight. |
@mochiya98, thank you for the self-contained repro! I ran your code for about 200 iterations, but I did not reproduce the behavior. This included some testing with a throttled network. Can you help me by providing the following:
|
This bug is very difficult to reproduce under reproducible conditions.
full dump(too long)
important things: nothing error occouced. when the bug occurs, only the onSnapshot of the deletion of one of the two documents is returned; 45 seconds later, the onSnapshot of the other document is reflected with a delay.
|
Thanks for the logs, now I can also reproduce. This appears to be related to a client-side index. I don't have a root cause yet, but I do have a workaround. The workaround requires deleting any existing client side indexes and ensuring client side index auto creation is disabled for now.
If you do need client side indexes for other collection, you could create those with the (deprecated) setIndexConfiguration(firestore, configuration). |
I have tried that code. I just added that code right after |
Interesting, can you confirm if there are any index configurations IndexedDB? Chrome Developer Tools > Application > Storage > IndexedDB > firestore/[DEFAULT]/yourprojectid/main > indexConfiguration. |
empty. output.mp4 |
This error message is indicating issues with using persistent single tab cache in an app that is open in multiple tabs.
The slow getDocs() call may also be related to this. Are you able to use the multi-tab persistence manager instead of the single-tab manager?
|
I was only illustrating that error as a possible fallback as to why the bug is not reproduced in your environment. Just to be sure, I tried the persistentMultipleTabManager, but the bug still occurs. |
Any update on this case? |
This one has been challenging to debug due to the frequency of occurrence. I believe it is triggered by an existence filter mismatch, which uses a probabilistic data structure and may explain the random occurrence. The reproduction that you've provided has been helpful, but it's not clear if this rapid sequence of set/create, delete, getDocs is the only time it is seen. Do you use the same rapid sequence of calls in your app, or is this only for the reproduction? If so, what is the use case for this sequence of calls? |
This reproduces the actual processing flow of the product. |
Any update on this case? |
@mochiya98, We've had a handful of people look at this issue. We are trying to move it forward. But given that the issue does not appear to be widespread, and that we have to prioritize the fix among other high-priority work, I can't provide you with a timeline for a fix. |
@MarkDuckworth Our product needs a fix for this. We have waited long enough. Can you fix this within a month? If not, we will give up using firestore and use another product. |
Fix is in main and will be included in the next release, likely in mid-November. |
Oh i'm glad this is fixed. This issues been causing a lot of production issues for us as well. |
Operating System
macOS Sonoma 14.4
Environment (if applicable)
Chrome 127.0.6533.100
Firebase SDK Version
10.13.1
Firebase SDK Product(s)
Firestore
Project Tooling
No-bundle (using cdn to reproduce)
Detailed Problem Description
Steps and code to reproduce issue
The text was updated successfully, but these errors were encountered: