firebase-ios-sdk
firebase-ios-sdk copied to clipboard
firebase
Realtime Database: unknown issue intermittently causing app to not connect to database after 10.25.0
Description
We recently released an update to our React Native mobile app that included an upgrade of @react-native-firebase/database from 19.0.0 to 21.0.0, which caused the corresponding Firebase/Database pod to upgrade from version 10.21.0 to 11.2.0.
Although we did not manage to reproduce the issue ourselves, which unfortunately means we do not have any logs, we received an influx of user reports after releasing this update of app behaviour that made it clear that no data was loading from Realtime Database after upgrading to this version. For any given user, the behaviour was intermittent - they could usually fix it temporarily by closing (swiping away from recents) and re-opening the app. Affected users were spread across iOS versions from 16.x to the latest 18.1.1 (i.e. versions much newer than those with the iOS 15 NSURLSessionWebSocket permessage-deflate bug).
After looking through everything that had changed in that version, we identified this upgrade of @react-native-firebase/database (and in turn the Firebase/Database pod) as a potential culprit, and in particular our attention was drawn to the following change in version 10.27.0 of the pod:
[RTDB] Use NSURLSessionWebSocket instead of SocketRocket where possible by @paulb777 in https://github.com/firebase/firebase-ios-sdk/pull/12894
As such, we released another app update in which the only change was to roll back @react-native-firebase/database from 21.0.0 to 20.0.0, which rolled the Firebase/Database pod back from 11.2.0 to 10.25.0 (the version just before the aforementioned change).
This resolved the issue - we stopped receiving those reports after users updated to this app version - so we do believe that that change seems like the most likely culprit. I know this doesn't provide enough information to reproduce and resolve the issue, but I'm hoping it will at least be a starting point in case anyone else has experienced anything similar, or has any ideas.
There is one iOS bug (that will most likely never be fixed) that I've faced before / am aware of that feels like it could somehow be relevant or at least worth looking into - perhaps SocketRocket previously included a workaround for it - but it could also be totally unrelated: https://stackoverflow.com/a/63626414/16739999
Reproducing the issue
No response
Firebase SDK Version
11.2.0
Xcode Version
15.4
Installation Method
CocoaPods
Firebase Product(s)
Database
Targeted Platforms
iOS
Relevant Log Output
No response
If using Swift Package Manager, the project's Package.resolved
No response
If using CocoaPods, the project's Podfile.lock
No response
I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
Hi @duncannz, I'm unable to reproduce the issue on native iOS SDK. this seems related to the issue introduced on v10.27.0 but this has been fixed on v11.2.0 based on the release notes.
Hi @rizafran, I'm unable to reproduce the issue either, so it is based on user reports (and the fact that just rolling back the SDK version resolved the issue) as described in the original post. However, version 11.2.0 was the problematic version, so whatever the issue is, it is not fixed in version 11.2.0. I'm hoping that someone else may have more information to share such as logs when the issue occurs, which we unfortunately do not have available.
@duncannz Thanks for the detailed issue report and suggestion about a possible solution path. This may be another incarnation of #13877
cc: @ncooke3
Thanks @paulb777, it does look potentially similar to #13877 and #9682. One difference is that we do not use App Check, whereas the author of #13877 suggested that removing App Check worked around the issue. But perhaps it is something like a race condition where the apparent involvement of App Check may be coincidental.
@paulb777 @ncooke3 We're on the latest version 11.6.0 and this could be potentially disastrous for us. I personally already hit this issue 3 times. Just randomly after not using the app for some time 10-30min or so and bringing the app up from background, the real time database won't connect at all. Can you please help?
@JCsplash if you are able to reproduce the issue yourself, perhaps it would be possible for you to capture logs when it occurs? I'm sure this would help the Firebase team to diagnose the issue
@duncannz @ncooke3 @paulb777 we unfortunately had to roll back from 11.6.0 to 8.8.0 because of this issue. It's hard to reproduce reliably when connected to debugger. The disconnection usually happens after an arbitrary amount of time with the app in the background. It's confirmed to occur on different iPhones with different firebase accounts. It also occurs on Mac. It would be great if you guys can also help reproduce the issue. We will continue to try to do so while connected to xcode but this is quite time consuming and we've been trying without luck.
@JCsplash unfortunately we also were unable to reproduce the issue ourselves and had to roll back the version that we use. However, as mentioned in my original post we successfully mitigated the issue by rolling back to version 10.25.0 (just before #12894 which seems to me like the most likely culprit), so you probably don't have to roll back as far as version 8.8.0.
We have also faced a reconnecting issue and believe it may have been introduced in this PR: #13564 (in particular the removal of the enteringForeground check but cannot say for certain)
This was released in 11.2.0, and once we upgraded it caused data not to sync when the app goes to the background and comes back to the foreground, until the app is restarted. Rolling back to a version before that (we went down to 11.0.0) solved the issue for us.
We also don't unfortunately have a way to consistently reproduce in our testing, and it didn't happen consistently with our customers either, but our customers were reporting issues related to data not being synced pretty much immediately from the release of the problematic version; and the only thing that worked for them was killing and re-opening the app. Once we released a new version of our app, with the downgraded dependency, everything has been working fine since then.
We don't want to lock ourselves in to a particular version, but have no choice right now and because of how hard it is to test and reproduce we have not been upgrading to any recent release as looking at the same file on main it seems there is still no check put back in place.
Experiencing the same issue, main issue is no reconnection, and then the data is not synced properly either after writing data offline.
We've restored the old Socket Rocket implementation in #14427 that should address the connectivity regression that the alternative NSURLSessionWebSocket seems to have introduced.
We're targeting to release 11.9.0 the week of February 24, 2025
As mentioned above, we encountered this issue when upgrading to v11+ and then had to downgrade to v8.8.0— But downgrading causes significant analytics inconsistencies :(
The downgrade led to our analytics data, specifically Weekly Active Users (WAU) and Monthly Active Users (MAU), being double-counted. This has disrupted our yearly analytics, and unfortunately, the only fix we found was to wait for the data to normalize over the following month. We reached out to Google support, but they weren’t able to provide a solution.
@paulb777 — would you be able to look into why downgrading causes this analytics issue? Understanding the root cause could help prevent similar problems in the future. Hopefully v11.9.0 works and no one would even need to downgrade!