Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Realtime Database: unknown issue intermittently causing app to not connect to database after 10.25.0 #14188

Open
duncannz opened this issue Nov 28, 2024 · 5 comments

Comments

@duncannz
Copy link

duncannz commented Nov 28, 2024

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 #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

@google-oss-bot
Copy link

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

@rizafran
Copy link
Contributor

rizafran commented Dec 2, 2024

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.

@duncannz
Copy link
Author

duncannz commented Dec 3, 2024

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.

@paulb777
Copy link
Member

paulb777 commented Dec 3, 2024

@duncannz Thanks for the detailed issue report and suggestion about a possible solution path. This may be another incarnation of #13877

cc: @ncooke3

@duncannz
Copy link
Author

duncannz commented Dec 3, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants