FR: Disable GC when file protection is enabled

[wilhuff]

We discovered in #2846 that if an app opts into complete file protection with NSFileProtectionComplete, the background GC task can crash the process if it runs while the filesystem is locked. The issue is that GC generates LevelDB commits which modify the filesystem, and while file protection is active, LevelDB sees these as I/O errors.

As file protection becomes active, users can currently disable listeners and stop sending writes, but there's nothing they can currently do about the GC background task. This FR is a request to have the GC task check whether or not protection is enabled, and if so, treat that GC cycle as a no-op.

Googlers see b/147764079 for more information.

[bivant]

Hello.
Any news on the Firebase + App running in background case with NSFileProtectionComplete on?
I experience crashes on Firebase (10.10.0). Can't find any workaround except drop the encryption which is not approved by the management.

[dconeybe]

Unfortunately, we don't have a fix for this issue yet. It's been in our backlog so thank you for raising it. I cannot provide any estimated timelines for a fix.

There are two workarounds that I can suggest though.

Workaround 1: Disable GC

Disable GC in the Firestore settings by setting cacheSizeBytes to FirestoreCacheSizeUnlimited. The drawback of this workaround is that the size of the local cache will grow unbounded.

Workaround 2: Terminate/Recreate Firestore

Call Firestore.terminate() when filesystem access is revoked. This will stop all background processing, including GC. Then, when filesystem access is reacquired create a new Firestore instance and re-register snapshot listeners with it. The drawback of this workaround is the complexity of swapping out an old Firestore instance with a new one and avoiding using the old one after calling terminate().