unexpected: AngularFirestore#collection() returns cached value on initial subscription

[jorroll]

Version info

Angular: 7.2.5
Firebase: 5.8.3
AngularFire: 5.1.1
Other (e.g. Ionic/Cordova, Node, browser, operating system): node 10.14.2, macOs X

How to reproduce these conditions

I've had some trouble isolating the exact problem. Basically, I have a people collection. If I fetch an individual document from the people collection (lets call it the person A doc), and then subscribe to the entire people collection, I'm seeing that the collection('people').valueChanges() subscription immediately returns an array that just contains person A. The subscription then fires again shortly later with the full results of the person collection.

If I invoke collection('people').valueChanges() before fetching an individual document from the people collection, then collection('people').valueChanges() returns the correct results on the first try.

What I think is happening, is that collection('people') is immediately returning results from an in-memory cache and then updating those results when it hears back from the server. I could see scenarios where this behavior would be desirable, but it is not desirable in my case, was unexpected and hard to diagnose, and there doesn't seem to be an option to disable it. I'm not sure if this is intended behavior or a bug.

I think it's possible that issue #1975 is being caused by the same problem.

In my case, the problem with this behavior (other than the fact that it is unexpected) is that I want to take(1) from the collection('people').valueChanges() query, except now the return value of that action is indefinite.

Debug output

I have none. I did try to set firebase.database().enableLogging(true); as suggested, but this.angularFirestore.app.database() does not have an enableLogging() function.

Expected behavior

By default, I expected query results to not be returned unless they accurately reflect the query.

I could see value in returning results immediately from a cache, but I don't think this behavior should be the default as it's unexpected, hard to diagnose, and can lead to unwanted behavior.

Actual behavior

AngularFirestore#collection() seems to return results immediately from the cache and then update the results when it hears back from the server.

[diginikkari]

I have been hit by this very badly. In my opinion it is a bug.

example:

you have collection where you have following docs:
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

If you have open subscription to item no 9 and you make query where you limit to 5 first items with take(1) you will receive item [9] instead of [0, 1, 2, 3, 4].

Sample project: https://angular-f6nfor.stackblitz.io

This makes e.g. pagination queries unreliable. When you relay that last item received will be last item of your previous pagination query and you use this item as startAfter for next query.

[jamesdaniels]

This is how the Firestore JS SDK works. I'm considering an API change that would allow you to inspect the metadata and say filter { snap -> !snap.metadata.fromCache } on snapshotChanges()

[jek-bao-choo]

Experiencing this bug too!

[tmk1991]

Anything would help! Glad someone brought up my old issue from a while ago.

[jek-bao-choo]

@tmk1991 How did overcome the problem all these while?

[jek-bao-choo]

I used a worked around...

you have collection where you have following docs:
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

If you have open subscription to item no 9 and you make query where you limit to 5 first items and explicitly with a where clause that says item that is not previously projected.

Put another way, query with exclusion to not include no 9.

[tmk1991]

I use the get() call for one of the queries and snapshotChanges() for the other.

[jorroll]

@jamesdaniels I can't speak for everyone, but your proposed update would address the problems I am experiencing.

[jek-bao-choo]

I use the get() call for one of the queries and snapshotChanges() for the other.

Sounds like another good workaround without adding additional index :)

[ColinBrilliantLabs]

I'm having this same issue but with the first valueChanges() being for an auth user, and the second valueChanges() to display all users. It displays the logged in user first, and then after a second or two displays all of them. I'm using ionic 4 and angular 6, but I can't figure out how to use the get() method as suggested. It seems to return metadata. Does anyone have another solution? I need this asap for work haha.

[ColinBrilliantLabs]

So I came up with a solution, but it's pretty hacky. Basically, I have a value change that fires off every time the db is updated, and then in that value change I have a get() for the exact same documents. This way the get it called every time the db updates, and doesn't get the cached results.

For those that had trouble figuring out how to use the get method:
this.userService.getUsersCollection().valueChanges().subscribe(() =>{
this.userService.getUsersCollection().ref.get().then(usersArray=>{

             usersArray.forEach(user => {
                 
                 this.users.push(user.data());

[tmk1991]

@ColinBrilliantLabs that would cause duplicate read costs. You can use get() as a promise based return of the documents

[ColinBrilliantLabs]

Yeah I know but get() doesn't provide live reloading, unless I did something wrong. If static content is what you need, then get() by itself is fine. The duplicate read cost is what I found to work with live reloading. If you can do that with get() though, please correct me.

[tmk1991]

you cant. tradeoffs sir :)