-
Notifications
You must be signed in to change notification settings - Fork 1.6k
[Firestore] getDocumentsWithCompletion does not pull from cache when app is in offline mode. #485
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
Comments
Question: at step three you're getting a callback to If that's the case this is a very serious bug :-(. |
Hey Gil. Yes that is correct. Let me know if you need some code/logs.
… On Nov 22, 2017, at 12:41 PM, Gil ***@***.***> wrote:
Question: at step three you're getting a callback to getDocumentsWithCompletion but the snapshot you're getting doesn't include the write from step 2?
If that's the case this is a very serious bug :-(.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
If you call [FIRFirestore enableLogging:YES] and send that over after
reproducing it would be very helpful.
If the log contents are at all sensitive feel free to send them directly to
me at [email protected].
On Wed, Nov 22, 2017 at 11:59 AM Luke Geiger <[email protected]>
wrote:
… Hey Gil. Yes that is correct. Let me know if you need some code/logs.
> On Nov 22, 2017, at 12:41 PM, Gil ***@***.***> wrote:
>
> Question: at step three you're getting a callback to
getDocumentsWithCompletion but the snapshot you're getting doesn't include
the write from step 2?
>
> If that's the case this is a very serious bug :-(.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub, or mute the thread.
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#485 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AJxjkIbsdPyjskiOq26nbcsvokWIT03iks5s5GD0gaJpZM4QnHQq>
.
|
Hey will here are my logs from the following situation. I emailed them to you.
|
To add to this, the property change I made in point#3 isn't anywhere in the logs. However, this change does propagate to the model once I regain internet access, and the updates take affect so its not like its completely disappearing. The issue seems to be that the getDocuments request doesn't pull ever from an updated cache? |
Want to bump this thread as I think there is a pretty big issue here and its currently severely impacting my apps performance. Please let me know If I can be of any further help. |
I can't reproduce what you're describing. I've written an additional test that specifically attempts to do what you've written up and the test is able to observe the new values: Does the test here actually implement what you've described? So long as the document already exists, updates to the document will be visible offline. If this test implements what you've described could you share a small program that reproduces what you're seeing? |
@wilhuff Gotcha, I just emailed you a sample project. |
So good news, bad news. The good news is that with the sample and the Network Link Conditioner I was able to reproduce the problem. Further good news is that you're experiencing a known issue that we're already working on fixing. The bad news is that the fix is not easy and won't happen right away. The Firestore SDK uses gRPC as its transport to the backend. When you force the connection to 100% packet loss gRPC is slow to fail the RPC stream. Firestore, in turn is conservative about transient failures and tries one more time to connect to the backend. The combination means that in this scenario it can take upward of 3 minutes for the Firestore client to determine that it's offline. The specific problem you're encountering is that while the Firestore client thinks its online If you wait that long you'll see the result you want. The work-around for now is to use a listener. You can either start one in the background and just keep the latest snapshot around for your call to getNotesWithCompletion or start one in there and wait for a little bit to see if you can get fresh results from the server. |
Gotcha thanks for digging. Sounds like a pretty serious issue. I've actually tried the listener approach, and although I can see my writes instantly after an update while offline, they wont persist after app launch. So for example If I do the listener approach, make an update while offline, kill app and come back the change wont be there anymore. I can prob swap around that demo project I made to replicate if you need me to reproduce. |
hey @wilhuff any update on this one? |
We're currently working on this fix (though the first implementation is in the javascript SDK). |
Hey Gill thanks for the quick reply and awesome to hear it is being worked on. What about what I mentioned with the listener approach also not working quite right? Any ideas there? |
Thank you for finding this, have you found any workaround so that you can effectively update and then query the updated local database while offline ? |
[REQUIRED] Step 3: Describe the problem
getDocumentsWithCompletion does not pull from cache when app is in offline mode.
Steps to reproduce:
I have been able to sort of work around this by instead of calling getDocumentsWithCompletion I am calling addSnapshotListenerWithOptions on a query and I am then getting a updated value when I re query again offline, however if I relaunch the app any updates I made to any object are again gone.
I really don't want to use any snapshots in my application, I never have a time where I need a constant connection on something and I never want to manage the listeners on a snapshot. My desired use case is to just pull from my database once, either from web while having an internet connection, or from the cache while offline, without having to juggle listeners. Is this possible?
In short, how does one update an object while in offline mode and see those changes persist?
The text was updated successfully, but these errors were encountered: