Possible bug in “queryOrdered(byChild:).queryEqual(toValue:).getData" function

[fawzialrifai]

[REQUIRED] Step 1: Describe your environment

• Xcode version: Version 12.5 (12E262)
• Firebase SDK version: 8.1.1
• Installation method: Swift Package Manager
• Firebase Component: Database

[REQUIRED] Step 2: Describe the problem

Steps to reproduce:

What happened? How can we make the problem occur?
I’m observing how many children a person called "james" has using child("james").child("children").observe(.value) function, in my case he has 2 children called "child1" and "child2" so it prints children count = 2. Then I check if "james" has a child called "child2" using child("james").child("children").queryOrdered(byChild: "name").queryEqual(toValue: "child2").getData function, in my case he has a child called "child2" so it prints found. Then unexpectedly the first observe function that observes and prints children count triggers again and prints children count = 1. I think the first observe function should not trigger and the children’s count should remain at 2. If I replace getData function with observe function to search for a child named "child2" it finds it and prints found and the first observe function that observes and prints children count does not trigger and the children count remains 2.

If you have a downloadable sample project that reproduces the bug you're reporting, you will
likely receive a faster response on your issue.
https://github.com/fawzialrifai/People

Relevant Code:

import UIKit
import Firebase

class ViewController: UIViewController {
    
    override func viewDidLoad() {
        super.viewDidLoad()
        Database.database().reference().child("james").child("children").observe(.value) { snapshot in
            print("number of james children = \(snapshot.childrenCount)") // observe and print james children count
        }
        Database.database().reference().child("james").child("children").queryOrdered(byChild: "name").queryEqual(toValue: "child2").getData { error, snapshot in
            if snapshot.exists() {  // search for james child named child2
                print("found")
            } else {
                print("not found")
            }
        }
    }

}

[jmwski]

Apologies for the delay on this. It looks like you're using v8.1.1 of the SDK. Could you try >= v8.5.0, which contains an important fix for the getData endpoint?

FWIW, I tried to reproduce the issue you've described in this draft PR: https://github.com/firebase/firebase-ios-sdk/pull/8618/files and was not able to get the observer to fire a second time as you described.

[fawzialrifai]

@IanWyszynski I still get the same output in version 8.6.1 can you please download my file and run it? it's just 7 lines.
https://github.com/fawzialrifai/People

[fawzialrifai]

@IanWyszynski @schmidt-sebastian @jeremydurham so this issue is still not fixed after 10 months?

[jmwski]

@IanWyszynski @schmidt-sebastian @jeremydurham so this issue is still not fixed after 10 months?

Apologies for the delay on this. I'll have a look at this again today.

[fawzialrifai]

@IanWyszynski thank you, hope you can fix it.

[jmwski]

@IanWyszynski thank you, hope you can fix it.

I investigated this issue for a few hours yesterday. The problem here is with the way that getDataWithCompletionBlock interacts with the listener cache. Specifically, it is the applyServerOverwriteAtPath that is causing this problem.

It's easy enough to remove that call and make your code sample work, but getDataWithCompletionBlock was added to address an issue with offline persistence where a single-value event listener optimistically checks cache before reaching out to the server on first startup (see this post). In order to address this problem, get has to properly update local cache.

We'll need to either figure out how to merge get responses into the local cache, or re-implement get to wrap a once-listener, but only fallback to it's results if the server is unresponsive. I'm going to take a stab at implementing the later, but the fix we ultimately decide on will require some discussion, so it might take a few days. I'll update this issue with any developments.