Firebase-ios-sdk: Path .info/connected returns NO with good connection

[brurend]

Step 0: Are you in the right place?

• For issues or feature requests related to __the code in this repository__
  file a Github issue.
  
  
  
  • If this is a __feature request__ please use the Feature Request template.
  
  
• For general technical questions, post a question on StackOverflow
  with the firebase tag.
• For general (non-iOS) Firebase discussion, use the firebase-talk
  google group.
• For backend issues, console issues, and other non-SDK help that does not fall under one
  of the above categories, reach out to
  Firebase Support.
• Once you've read this section and determined that your issue is appropriate for
  this repository, please delete this section.

[REQUIRED] Step 1: Describe your environment

• Xcode version: 11.3
• Firebase SDK version: 6.16.0
• Firebase Component: Database
• Component version: 6.1.4
• Installation method: CocoaPods (select one)

[REQUIRED] Step 2: Describe the problem

Steps to reproduce:

What happened? How can we make the problem occur?
We use the .info/connected to make sure Firebase is online but it quite often returns NO even when the phone internet connection is working fine and without any issues. Not sure if its a bug, a mistake in our implementation or if thats normal to happen.

If you have a downloadable sample project that reproduces the bug you're reporting, you will
likely receive a faster response on your issue.

Relevant Code:

Database.database().reference(withPath: ".info/connected").observe(.value)
        {[weak self] (snapshot) in

            if let unwrappedIsConnected = snapshot.value as? Bool {

                if(unwrappedIsConnected){

                    SwiftMessages.hide(id: "messageCantReachServer")

                    if let unwrappedTask = self?.task {

                        unwrappedTask.cancel()
                    }
                } else {

                    self?.task = DispatchWorkItem { self?.showMessageCantReachServer() }

                    if let unwrappedTask = self?.task {

                        DispatchQueue.main.asyncAfter(deadline: DispatchTime.now() + 3, execute: unwrappedTask)
                    }
                }
            }
        }

[rizafran]

Thanks for reporting, @brurend. Have you tried using other networks? It works fine on my end using quickstart for Database.

[maksymmalyhin]

@brurend To get more info about the reason why .info/connected may indicate disconnected state even with a reliable network connection you may enable debug logging (by passing the -FIRDebugEnabled argument to the application) and observe console messages with the [Firebase/Database] tag. It should contain messages about Firebase Database connection attempts and errors. Feel free to share the messages so we can get better understanding of your issue.

[brurend]

Thats a common report from our users so it happens in many different networks. Also we have seem it happens simultaneously in 4 different devices and each using their own cellular data and not the same network.

I will try to see what I can get from the console messages and send it here.

[brurend]

I tried logging messages with the database tag but it didn’t show anything. I see logs from the other tags, like analytics but nothing from database

[maksymmalyhin]

Note: may be related to #4913

[brurend]

Is it possible that this happens because of an overload of simultaneous connections? Too many request being made at the same time causing the database to be slow and eventually not answering at all.
Also, our app is based on Brazil, maybe the distance to the Firebase servers could have any influence?

[morganchen12]

Database uses a single websocket connection behind the scenes, so additional requests doesn't increase the amount of connections, only the amount of data transferred over the single connection.

If you're able to find a tester in another region and they don't have the issue, it may be a Brazil-localized issue.

[maksymmalyhin]

@brurend As for the debug logs - it appeared that Database SDK has additional log level control, so to enable debug logs you will need to o BOTH:

• add Database.setLoggingEnabled(true) line to your code before FirebaseApp.configure()
• pass the -FIRDebugEnabled argument to the application

The logs with the connection error description will help us to understand the reason of your issue.

[maksymmalyhin]

Created #4958 to reconsider Database log level control.

[brurend]

@brurend As for the debug logs - it appeared that Database SDK has additional log level control, so to enable debug logs you will need to o BOTH:

• add Database.setLoggingEnabled(true) line to your code before FirebaseApp.configure()
• pass the -FIRDebugEnabled argument to the application

The logs with the connection error description will help us to understand the reason of your issue.

I'm still not seeing any logs from database, but it might be something wrong on my initialisation because I'm getting these logs:

2020-02-24 16:49:27.122206-0300 App 6.16.0 - [Firebase/RemoteConfig][I-RCN000047] FIRApp not configured. Please make sure you have called [FIRApp configure]
2020-02-24 16:49:27.122367-0300 App 6.16.0 - [Firebase/Core][I-COR000003] The default Firebase app has not yet been configured. Add `[FIRApp configure];` (`FirebaseApp.configure()` in Swift) to your application initialization. Read more: https://goo.gl/ctyzm8.
2020-02-24 16:49:27.122417-0300 App 6.16.0 - [Firebase/RemoteConfig][I-RCN000047] FIRApp not configured. Please make sure you have called [FIRApp configure]
2020-02-24 16:49:27.122449-0300 App 6.16.0 - [Firebase/Core][I-COR000003] The default Firebase app has not yet been configured. Add `[FIRApp configure];` (`FirebaseApp.configure()` in Swift) to your application initialization. Read more: https://goo.gl/ctyzm8.

However I'm calling FirebaseApp.configure() at AppDelegate init method, before anything else

[morganchen12]

Do you have duplicate class definition warnings in your app's runtime?

[brurend]

Do you have duplicate class definition warnings in your app's runtime?

I had both -FIRDebugEnabled (ON) and -FIRDebugDisabled (OFF) there, I removed the disabled and now I'm seeing Database logs, I will see what I can find to send here when the error happens.

But I'm still getting the warnings I mentioned in my last reply about FirebaseApp.configure()

[morganchen12]

The duplicate class definitions will be printed by the objc runtime (not Firebase) and are usually at the very top of your app's logs.

[maksymmalyhin]

Firebase Performance may attempt to access Remote Config at early app startup stages, so if there are no duplicate class definitions, the warnings are most likely irrelevant for the current issue.

[brurend]

I did manage to get console logs from the moment the app was with the issue. Would there be an email I could send you the logs? Its quite a bit of information and also I'm not 100% comfortable in posting all the logs here in public.

[maksymmalyhin]

@brurend You may either send the logs to my email [email protected] or create a Firebase Support case mentioning the GitHub issue and my GitHub username, so the support team can forward the minimal required information to me.
Independently on the option you prefer, I would encourage you to remove any private information unrelated to the issue from the logs. For the beginning, we will need only logs with [Firebase/Database] tag. Thanks!

[google-oss-bot]

Hey @brurend. We need more information to resolve this issue but there hasn't been an update in 7 weekdays. I'm marking the issue as stale and if there are no new updates in the next 3 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[google-oss-bot]

Hey @brurend. We need more information to resolve this issue but there hasn't been an update in 5 weekdays. I'm marking the issue as stale and if there are no new updates in the next 5 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[google-oss-bot]

Since there haven't been any recent updates here, I am going to close this issue.

@brurend if you're still experiencing this problem and want to continue the discussion just leave a comment here and we are happy to re-open this.