-
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
Firestore batch deletes emit a snapshot per delete #13883
Comments
I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight. |
I think either this or something similar was previously reported here: #5955. To respond to #5955 (comment): Using Even if I do nothing in my listener, the CPU usage and heat generated by firestore are high. My app is also killed in the background when it would otherwise be allowed to run, presumably due to the high resource usage. |
Also, what server SDK and version are you using? |
I've updated the iOS client to 10.29.0 and can still reproduce using the steps I listed above 100% of the time. Ditto for Android on version 33.4.0. I'm using 6.5.0 of the firebase admin sdk. Here's the specific query I'm using:
I'd be happy to provide sdk logs if you can tell me how. I do not have time to extract a demo app unfortunately. |
@sjudd, To securely share a log, one way is to submit a firebase support case and attach the generate log in a file. Please reference internal bug b/373374534, so the team can route the log to the correct place. Thanks! |
I've sent a support case and referenced the bug you mentioned: 10314628 |
@sjudd, I was not able to get your logs. Can you confirm the status of the support case you opened to share the logs? Also, confirm that your referenced the correct bug in your support request: "b/373374534". |
I received an email on 10/22 indicating that the case was received. The title is Subject: b/3733745 Firestore iOS and Android emit snaphots per delete from batch deletes. I think that's the bug you mentioned in the Android thread. I'll ask them to include this bug as well. |
Description
Batch deletes cause the firestore ios client to emit a snapshot for every individual delete, which creates an exponential (edit: N + N-1 + N-2, triangular?) amount work decoding every document in each snapshot.
I would expect to get a single snapshot for the single batch delete. Firebase's documentation says "A batch of writes completes atomically and can write to multiple documents". The documentation seems to recommend batch writes over transactions for cases where you're not reading: "Like transactions, batched writes are atomic. Unlike transactions, batched writes do not need to ensure that read documents remain un-modified which leads to fewer failure cases."
I'd also expect that if multiple changes happen in the background, the next time the ios client connects, it emits a single snapshot with that complete set of changes, not one snapshot per change.
Reproducing the issue
Write 500 documents to a Firestore collection using Firestore's batch API with an admin SDK.
Observe the collection in a snapshot listener on iOS.
Receive a single snapshot update from network with 500 documents (WAI)
Then, using the same batch API, delete all 500 visits, roughly:
On the client, add a snapshot listener to the collection:
Receive separate snapshots marked "from cache" for every single delete:
If you do this with a collection of 5000 items and you decode every item in each snapshot on the client, you end up decoding ~12 million documents during this process (5000 + 4999 + 4998 etc). Firebase also seems to emit the snapshots quite slowly (< 1 per second at the start). This is pretty catastrophic for app performance and users' battery life.
I also see this behavior for Android FWIW.
Firebase SDK Version
10.24.0
Xcode Version
15.0.1
Installation Method
Swift Package Manager
Firebase Product(s)
Firestore
Targeted Platforms
iOS
Relevant Log Output
No response
If using Swift Package Manager, the project's Package.resolved
Expand
Package.resolved
snippetReplace this line with the contents of your Package.resolved.
If using CocoaPods, the project's Podfile.lock
Expand
Podfile.lock
snippetReplace this line with the contents of your Podfile.lock!
The text was updated successfully, but these errors were encountered: