Firestore not run offline when (4g is online but without payment)

443 views
Skip to first unread message

SDK

unread,
Nov 7, 2017, 12:30:56 PM11/7/17
to Firebase Google Group
Hi, I started use firestore, different of firebase it's slow but it's beta so no problem for now.

But, if use 4g and it's down (connected but no have internet because payment or provider offline for eg.) the firestore data never return, waiting forever. I think it is not know about status of internet 4g.

Any one know anything about it?

Thanks

Bartholomew Furrow

unread,
Nov 10, 2017, 2:23:22 AM11/10/17
to Firebase Google Group
I've encountered what sounds like the same issue when the user has a network connection but no internet access. Some kinds of responses return from the cache, and others (e.g. queries with no results) don't return at all, even if their results should be cached. I filed it, and it has reference number 5-9835000019823 internally. Hopefully if that gets fixed, your problem will, too.

FYI mine is an issue with Swift in iOS. If you're having the same problem in Android, that would be more surprising. 

Michael Lehenbauer

unread,
Nov 10, 2017, 11:23:19 AM11/10/17
to Firebase Google Group
Hey Bartholomew,

What you describe may be expected behavior.  When the client detects it is offline, it will attempt to satisfy queries by using the local cache. But in the case of a query with no results, it won't find any matching documents in the cache, and so it won't raise the event (until you come back online).

Basically when its offline the client can't differentiate between "there are no results for this query" and "I don't happen to have any cached results for this query" and so it will not raise an event claiming there are no results, when it doesn't actually know.

I understand this may not be ideal. If you have a specific use case blocked by this, let me know. We're definitely open to feedback.

Thanks,
-Michael

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/fc056cb1-a465-4cfe-8f36-5cf6da962448%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Bartholomew Furrow

unread,
Nov 10, 2017, 12:54:02 PM11/10/17
to fireba...@googlegroups.com
Hi Michael,

My use case: a user needs to choose a friend. For that, the client needs to wait until the server (or cache) comes back with friends. But if the user has no friends and is connected to a network with no connection to Firestore, the cache will never come back and the app will hang.

There are more details than that -- my app actually has to issue four different queries, one for "I am someone's friend", one for "Someone is my friend", one for "I have invited someone to be my friend" and one for "Someone has invited me to be his or her friend", and if any of those hang then the whole page hangs -- but the previous paragraph should suffice, I hope.

I personally don't have a device that's frequently connected to a network with no connection to Firestore, but I'd like my app to work for users who do!

By the way, it's frustrating to learn that this is expected behaviour, because I've spent several hours over the course of the last week going back and forth on a bug report with an engineer who (a) asked for a repro, when apparently this is expected behaviour, and (b) couldn't reproduce the behaviour, costing both of us more time. I don't blame him for that -- nobody's an expert in everything -- but it's frustrating, and suggests to me that if I want to report a bug then this is a better venue than the official bug report form, because I'm more likely to have an expert spot a forum post than for an expert to be randomly assigned a bug. This is on issue 5-9835000019823.

Best,
Bartholomew

On Fri, Nov 10, 2017 at 9:23 AM 'Michael Lehenbauer' via Firebase Google Group <fireba...@googlegroups.com> wrote:
Hey Bartholomew,

What you describe may be expected behavior.  When the client detects it is offline, it will attempt to satisfy queries by using the local cache. But in the case of a query with no results, it won't find any matching documents in the cache, and so it won't raise the event (until you come back online).

Basically when its offline the client can't differentiate between "there are no results for this query" and "I don't happen to have any cached results for this query" and so it will not raise an event claiming there are no results, when it doesn't actually know.

I understand this may not be ideal. If you have a specific use case blocked by this, let me know. We're definitely open to feedback.

Thanks,
-Michael

On Thu, Nov 9, 2017 at 11:23 PM, Bartholomew Furrow <fur...@gmail.com> wrote:
I've encountered what sounds like the same issue when the user has a network connection but no internet access. Some kinds of responses return from the cache, and others (e.g. queries with no results) don't return at all, even if their results should be cached. I filed it, and it has reference number 5-9835000019823 internally. Hopefully if that gets fixed, your problem will, too.

FYI mine is an issue with Swift in iOS. If you're having the same problem in Android, that would be more surprising. 

On Tuesday, November 7, 2017 at 10:30:56 AM UTC-7, SDK wrote:
Hi, I started use firestore, different of firebase it's slow but it's beta so no problem for now.

But, if use 4g and it's down (connected but no have internet because payment or provider offline for eg.) the firestore data never return, waiting forever. I think it is not know about status of internet 4g.

Any one know anything about it?

Thanks

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.

To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/fc056cb1-a465-4cfe-8f36-5cf6da962448%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Firebase Google Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firebase-talk/lTykuiRsZzw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to firebase-tal...@googlegroups.com.

To post to this group, send email to fireba...@googlegroups.com.

Michael Lehenbauer

unread,
Nov 10, 2017, 6:09:30 PM11/10/17
to Firebase Google Group
Hey Bartholomew,

Thanks for the added info!

And I have 2 apologies for you:
  1. I was wrong. You should get a snapshot event with 0 documents in it, even if you're offline / unable to reach Firestore.  It may be slightly delayed though because (unlike when we have results from the cache) the client will wait until the connection to Firestore fails before raising the empty snapshot event. So you're right to call this a bug and you shouldn't be seeing the behavior you're seeing. I was mistaken in my original response. Sorry!

  2. Sorry for the runaround with the bug report.  That process is generally the best way to proceed as the engineers that field those requests have the bandwidth to reproduce the issues and verify they're real and actionable, although they are not the same engineers working on the product day-to-day so there are sometimes knowledge gaps. Sorry! FWIW- Your issue got escalated to a teammate of mine a couple days ago, and I just grabbed it from him so I can dig in and follow up with you.
I'll dig into this more on Monday and see if I can reproduce the issue, but it sounds like for some reason the client is waiting indefinitely for a response from the server rather than giving up and raising the event with cached data.  I will try to reproduce myself, but it may be environment-specific so if either of you can provide the following information, it would be helpful:
  1. If you wait long enough (e.g. 2 minutes), do you eventually get the event?
  2. Can you capture a log with Firestore.enableLogging(true) and send me the output?
Thanks!
-Michael
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.

To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/fc056cb1-a465-4cfe-8f36-5cf6da962448%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Firebase Google Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firebase-talk/lTykuiRsZzw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to firebase-talk+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.

To post to this group, send email to fireba...@googlegroups.com.

Bartholomew Furrow

unread,
Nov 10, 2017, 10:52:19 PM11/10/17
to fireba...@googlegroups.com
Michael,

It's much less frustrating if it isn't actually expected behaviour. :-) It isn't a runaround, either, if it's genuinely a bug that's hard to reproduce. So I feel better! A couple of thoughts:

Regarding your #1

> the client will wait until the connection to Firestore fails before raising the empty snapshot event

It sounds like that's the expected behaviour right now. Is that the desired behaviour, or simply an artifact of how the current system works? If the only way the client ever accesses collection X is with queries A, B, C and D, then (with an ideal caching system) the number of results any of those queries returned last time it was run doesn't seem like it should affect whether the query can hit the cache or not. I'm imagining the actual mechanism is that documents are cached, the method used to retrieve them isn't, and a query without results is much more likely never to have been issued than a query with them, which is why there's a difference in behaviour.

Regarding your #2

I'll reiterate that I don't feel like I got the runaround from you or Chiz. The only thing that made me feel that way was your previous email, which turned out to be mistaken anyway; it sounds like the work to reproduce this issue was valuable after all.

Other stuff

- When you look at the bug thread, please note that Chiz was seeing different weird caching results, though we didn't get very deep into that and I never saw anything like that at my end (he/she was seeing no results from the cache for a query that was returning a result seconds before).

- There is no response after 5 minutes.

- I've attached the extra logging in cacheproblem.txt. I set my computer to 100% packet loss at 20:45:05 or so, then issued the queries at 20:45:10. In this log, I reconnected at 20:45:39.

- Have a great weekend!

Cheers,
Bartholomew
cacheproblem.txt

Michael Lehenbauer

unread,
Nov 13, 2017, 3:36:59 PM11/13/17
to Firebase Google Group
Hey Bartholomew,

Re #1: You are correct.  We cache documents but not the mechanism used to retrieve them. And relatedly we only cache 1 version of any given document, which means your cache will be made up of documents at many different versions.  This is an intentional choice to ensure we present a consistent view across local queries you do regardless of when / how the cached documents were fetched.  For example if you did query A on day 1 and there were no results, but then on day 2 you do query B that includes a recently-created document "foo" that happens to also match query A, we want to make sure that if you do query A again then "foo" now shows up, even though it didn't exist (or didn't match) last time you did the query.  This generally matches the user's expectations (no matter how they're accessing documents, any UI in the app should reflect the latest state of the document that they've previously seen).  So in general, we always perform queries client-side against the latest state of the cached documents rather than infer anything based on the state of documents last time we happened to do the query.

FWIW- We expect that apps will show either nothing or a spinner while waiting for the initial snapshot event, and so in the case of "no documents match the query" it should be of little consequence whether we raise an empty snapshot immediately or only after we assume we are offline (which shouldn't take long).  But unfortunately, the "assume we are offline" bit seems to be broken here, so e.g. apps may end up with a perpetual spinner while offline, and we definitely want to look into that.

Thanks for the log and added info. If it doesn't fail after 5 minutes, that's pretty broken!  I'll dig into this and make sure I can reproduce the issue. Else, I'll ping you again shortly.  To be clear, do you consider this to be blocking your use case? Or do you have a suitable workaround for the time being?

Thanks,
-Michael

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.

Bartholomew Furrow

unread,
Nov 14, 2017, 3:09:48 AM11/14/17
to fireba...@googlegroups.com
Michael,

Thanks for the explanation! It's helpful to me to learn about the caching mechanism in a little more detail. This isn't blocking my use-case at all, and I'm happy with an eventual solution.

By the way, just making sure it doesn't get missed: look in the bug thread for where I call out the cached results Chiz is getting as weird (the second time; the first time I made a mistake). He/she is seeing 1 foo, then cuts the cord, issues a new query and sees 0 foos, then comes online and sees 1. That hasn't happened to me, but I don't want it to get dropped.

Cheers,
Bartholomew

To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.

To post to this group, send email to fireba...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Firebase Google Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firebase-talk/lTykuiRsZzw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to firebase-tal...@googlegroups.com.

To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CAJCySteV1diFcW-L8YDgbGGXesUTkM-uCrcb%2BsD2g3TEaXVuFQ%40mail.gmail.com.

Michael Lehenbauer

unread,
Nov 22, 2017, 2:06:31 PM11/22/17
to Firebase Google Group
Hey Bartholomew,

Sorry for the delay. I just wanted to follow up that:
  1. I've (mostly) reproduced your issue.  What I'm seeing (looking at logs enabled via Firestore.enableLogging(true)) is that it takes 3 minutes for our connection to fail, and we let it fail twice before we raise the event with cached data.  So if you wait ~6 minutes, you *should* get the event with cached data. But this is obviously not desirable behavior. I'm going to look into how we can tweak timeouts, etc. so this happens more quickly.

  2. Thanks for flagging the unusual behavior Chiz was seeing.  The behavior is consistent with offline persistence being disabled (e.g. via setting persistenceEnabled to false), so I'm following up with Chiz to see if that might have been the case (or dig into whether there's some other reason persistence wasn't working correctly).
Thanks,
-Michael

To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.

To post to this group, send email to fireba...@googlegroups.com.
You received this message because you are subscribed to a topic in the Google Groups "Firebase Google Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firebase-talk/lTykuiRsZzw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to firebase-talk+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.

To post to this group, send email to fireba...@googlegroups.com.

Bartholomew Furrow

unread,
Nov 22, 2017, 7:23:02 PM11/22/17
to fireba...@googlegroups.com
Michael,

It sounds like what you're seeing is consistent with what I'm seeing; thank you for following up with Chiz, as well!

Bartholomew

To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.

To post to this group, send email to fireba...@googlegroups.com.
You received this message because you are subscribed to a topic in the Google Groups "Firebase Google Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firebase-talk/lTykuiRsZzw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to firebase-tal...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.

To post to this group, send email to fireba...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Firebase Google Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firebase-talk/lTykuiRsZzw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to firebase-tal...@googlegroups.com.

To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CAJCyStcsF8UejiATtbMedunSJRVTfEe64iT2zNJpZJcTp%3DyMjA%40mail.gmail.com.

Cameron Mayfield

unread,
Feb 19, 2018, 8:50:07 PM2/19/18
to Firebase Google Group
Michael,

Any update on this? I'm still seeing this behavior in Android. 

Thanks!
Cameron

Bartholomew Furrow

unread,
Mar 2, 2018, 10:19:29 PM3/2/18
to fireba...@googlegroups.com
I'm seeing this behaviour in Android too, now. About a minute (it's been from 50-75 seconds in my last few trials) to confirm that a query has no results when offline.

I'm using com.google.firebase:firebase-firestore:11.8.0 on an emulated Pixel, again with a network connection but no internet connection.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/90d46db3-0c12-4989-b2e5-2c1e29b49861%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages