Firestore writing breaks in IOS background mode #3526
Comments
|
@ebeling Thanks for opening this issue. I don't see any error messages in the logs you provided. Do you happen to see any errors in the console? |
|
iOS locks the filesystem by default when your app is in the background. Firestore does not support this configuration. Either avoid writing to Firestore while in the background or change your entitlements to disable automatic filesystem locking. See #2846 for more details including which entitlement to change. Note that the file protection entitlement affects the default for new files but not existing ones. This means that changing the entitlement will not change any existing files and will not fix any users that already have created an instance. The same issue contains some example code for how to fix existing installations. |
|
Thank you for answer. Please help me: I don't use firestore messaging like descibed in #2846 and I don't use chrome extension, I use write to firestore. If firestore doesn't support this, why the document.set-method doesn't throw an error like "can not write because of no access to filesystem"? And firestore hangs, if the app comes back to the foreground, the app must be restarted ?! Do you mean firestore can not be used if writing in background is necessary? |
|
I'm so sorry! I meant to link you over to an issue in the iOS repository--I can see how that would be confusing! The issue to which I meant to refer you was firebase/firebase-ios-sdk#2846, wherein we discussed setting the If you need to write in the background, then either you need to set the entitlement that changes the filesystem protection level or you can't use Firestore. Fixing the SDK so that it provides an error in this case instead of throwing an Objective-C exception is on our list of things to do, but we haven't gotten to it yet. |
|
Thank you for reply. I read your big discussion and try to implement the file entitlement solution. If I understand right, I have to do this:
I determined that Xcode filled other key-value-pair in files "Entitlements-Debug.plist" and "Entitlements-Release.plist" (NSFileProtectionComplete is default value), I changed it to "NSFileProtectionCompleteUntilFirstUserAuthentication" outside of Xcode, because Entitlement-files were not visible in project navigator. After that no errors occurred with signature and profiles. But nothing changed in term of storing data in firestore in background mode. Do you know whether I can see on mobile device if the permission for store files is correctly built into my app ? |
|
The entitlement only affects the default for creating new files. Deleting the app should have cleaned up anything from before so this should have worked. You can check that it's taking effect with the code in firebase/firebase-ios-sdk#2846 (comment) Change the However, I suspect that since you're still reproducing the failure this somehow hasn't taken effect. @morganchen12 do you have any insight into whether something might be missing from the provisioning steps taken? |
|
The steps to update the app's entitlements look solid. You can force Xcode to refresh a provisioning profile by deleting that profile from the Xcode navigator and then re-downloading it, but based on the steps described I don't think this will have any effect. As @wilhuff mentioned you can use the @ebeling can you enable native logging via |
|
Thank you for your engagement! I use cordova and because of this the native code is written in objective-c. @wilhuff I can't copy your unlock-function, I transfered it to objective-c - (void) unlockFirestoreData
{
NSDictionary<NSFileAttributeKey,id> *attributes = @{NSFileProtectionKey:NSFileProtectionNone};
NSArray *dirs = NSSearchPathForDirectoriesInDomains(NSApplicationSupportDirectory, NSUserDomainMask, YES);
NSString *applicationSupportDirectory = [dirs firstObject];
NSLog(@"applicationSupportDirectory: '%@'", applicationSupportDirectory);
NSString *firestoreDir = [applicationSupportDirectory stringByAppendingString:@"/firestore"];
NSLog(@"firestoreDir: '%@'", firestoreDir);
NSFileManager* sharedFM = [NSFileManager defaultManager];
NSError *error = nil;
if (![sharedFM fileExistsAtPath: firestoreDir isDirectory:nil]) {
[sharedFM createDirectoryAtPath:firestoreDir withIntermediateDirectories:true attributes:attributes error:&error];
if (error) {
NSLog(@"ERROR while create firestore dir: '%@'", error);
return;
}
}
NSLog(@"state of firestore path: '%@'", [sharedFM attributesOfItemAtPath:firestoreDir error:&error]);
NSDirectoryEnumerator<NSString *> *files = [sharedFM enumeratorAtPath:firestoreDir];
NSString *file = nil;
while (file = [files nextObject]) {
[sharedFM setAttributes:attributes ofItemAtPath:file error:&error];
if (error) {
NSLog(@"ERROR while set file protection none '%@' with error '%@", file, error);
error = nil;
}
}
}The log for firestore path attributs is I downloaded app-container with Xcode device manager. I asked me, wherefrom should the javascript-firebase-sdk which is executed in Webview know the firestore path which is set in native environment? As you can see in appended app-container the IndexedDB-files are located under "AppData/Library/WebKit/WebsiteData/IndexedDB/v1/ionic_localhost_0/..." But if they are visible they should not be protected?! Here is the app-container |
|
Based on the log you posted, the access level of Firestore files shouldn't be causing write issues in the background: You can enable Objective-C level logging with the same Swift call, translated to Objective-C: [FIRFirestore enableLogging:YES]; |
|
I'm not sure that the problem has something to do with file entitlements. I performed some tests and observed logging in device console Test 1 (without any write calls)
Test 2
note: under Android the firestore logging in console takes place without stopping independent of app state (foreground/ background) |
|
Thanks for the logs. This clears up what's going on. The key part of the logs is This means you're running into the same issue as #3495. The good news is that we have a fix submitted in #3535 which should be released soon. (I believe this was submitted after the cut-off for this week's release, but it should be in the next release if everything goes well.) |
|
@wilhuff Thank you for new release (7.17.2) where the linked fix is included. I installed it. The behavior is different now. Unfortunately firestore still seems to crash. I tested in Test 1
corresponding log: I tested my issue described in Test 2. Here is my test sequence:
corresponding lo file: |
|
The most recent release does not contain the fix in #3535. As I said, this change landed after the cut-off for yesterday's release. The fix will be in the next release. In test 2, are you logging errors returned by the Firestore API while in the background? My understanding is that after IndexedDB locks, writes to Firestore should fail and we should be failing any writes or queries you try to make. |
|
Sorry, but if I go to firebase tag 7.17.2, than there are 9 commits including the commit for #3535 ( https://github.com/firebase/firebase-js-sdk/compare/[email protected] ) ? Both in test 1 and in test 2 no errors were thrown while writing in background, firestore freezes. |
|
@ebeling The link you posted shows the commits since 7.17.2. These are all the commits that are part of the release: https://github.com/firebase/firebase-js-sdk/commits/firebase%407.17.2 The changes in #3535 will be published this week. |
|
@wilhuff Thank you! I will wait for this release. I tried to build master branch, but this failed for me, I don't know yarn and after the commands 'yarn' and 'yarn build' I don't see the distribution ... |
[REQUIRED] Describe your environment
[REQUIRED] Describe the problem
Steps to reproduce:
I implement an Ionic/Cordova App with Angular Fire (5.4.2) and Firestore. The app receives data from bluetooth interface and stores data periodically in firestore. Firestore is configured using offline persistence. All works fine as long the app is in the foreground. But if it goes to the background firestore breaks without error. The app must be restarted to make firestore working again. I can certainly exclude a bluetooth interface failure. Data are also received in the background mode!
Thisonly happens in IOS - in Android storing the data works fine. Logging I have enabled:Could be related to #3495
Relevant Code:
After going into the background 'segmentDocument.set(...)' never resolves.
The text was updated successfully, but these errors were encountered: