firebase
Repeated Listen Calls observed via GCP Audio Logs
[READ] Step 1: Are you in the right place?
Issues filed here should be about bugs in the code in this repository. If you have a general question, need help debugging, or fall into some other category use one of these other channels:
- For general technical questions, post a question on StackOverflow with the firebase tag.
- For general Firebase discussion, use the firebase-talk google group.
- For help troubleshooting your application that does not fall under one of the above categories, reach out to the personalized Firebase support channel.
[REQUIRED] Step 2: Describe your environment
- Android Studio version: vscode
- Firebase Component: Firestore
- Component version: "@react-native-firebase/firestore": "19.2.2",
I do use React Native package, but it's using this SDK, so I'm posting here.
Using real Device, Pixel 7, Android 14.
[REQUIRED] Step 3: Describe the problem
Steps to reproduce:
- Create couple of collection listeners
- Observe many, many unnecessary
firestore.v1.Firestore.Listencalls
The logs indicate many repeated Listen calls without any data changes in the app and no requests being sent.
Around 25% of those Listen request fail with no particular reason, the Audit Logs just reports Fatal error. The app keeps working, but some user complain the data does not always load or update requests sometimes fail.
Strange. What I have checked is that I am not creating unnecessary listeners and I'm not using listeners outside of an Android app.
Relevant Code:
Maybe relevant: https://github.com/firebase/firebase-android-sdk/issues/3718
But these days the persistence option is enabled by default.
Interesting:
05-12 17:12:33.739 30069 27248 I NearbyMediums: Process on lost ble advertisements.
05-12 17:12:33.783 563 3036 D hwc-display: setActiveConfigWithConstraints:: PrimaryDisplay config(36) test(0)
05-12 17:12:33.784 563 3036 I hwc-display: [PrimaryDisplay] setActiveConfigWithConstraints: config(36)
05-12 17:12:34.371 970 970 I WifiHAL : Creating message to get link statistics; iface = 48
05-12 17:12:34.441 970 970 I WifiHAL : In GetLinkStatsCommand::handleResponse
05-12 17:12:34.535 1363 1986 D ConnectivityService: NetReassign [no changes] [c 6] [a 7] [i 19]
05-12 17:12:35.342 1363 1363 I ContentCaptureManagerService: Content capture data sharing session terminated successfully for package 'com.google.android.googlequicksearchbox'
05-12 17:12:37.498 970 970 I WifiHAL : Creating message to get link statistics; iface = 48
05-12 17:12:37.572 970 970 I WifiHAL : In GetLinkStatsCommand::handleResponse
05-12 17:12:37.617 1363 1986 D ConnectivityService: NetReassign [no changes] [c 2] [a 2] [i 7]
05-12 17:12:37.696 15474 15483 I com.houserion: Background concurrent mark compact GC freed 2232168(73MB) AllocSpace objects, 211(16MB) LOS objects, 70% free, 39MB/135MB, paused 728us,2ms total 175.204ms
05-12 17:12:40.609 970 970 I WifiHAL : Creating message to get link statistics; iface = 48
05-12 17:12:40.675 970 970 I WifiHAL : In GetLinkStatsCommand::handleResponse
05-12 17:12:40.768 1363 1986 D ConnectivityService: NetReassign [no changes] [c 6] [a 7] [i 21]
05-12 17:12:42.179 15474 15688 W Firestore: (24.11.1) [WatchStream]: (33e8a6e) Stream closed with status: Status{code=INTERNAL, description=Internal error
05-12 17:12:42.179 15474 15688 W Firestore: Rst Stream, cause=null}.
05-12 17:12:42.522 1363 1917 D ActivityManager: freezing 22925 com.whatsapp
05-12 17:12:42.533 1363 1986 D InetDiagMessage: Destroyed 0 sockets, proto=IPPROTO_TCP, family=AF_INET, states=14
05-12 17:12:42.539 1363 1986 D InetDiagMessage: Destroyed 1 sockets, proto=IPPROTO_TCP, family=AF_INET6, states=14
05-12 17:12:42.539 1363 1986 D InetDiagMessage: Destroyed live tcp sockets for uids={10306} in 11ms
At the same time I could observe failed requests:
EDITED
I've also simplified my setup and created only one collection listener. I've tested both iOS and Android.
- iOS device is constantly producing log entries.
- Android device is constantly producing log entries.
I am using App Check. If I compare JTW tokens between failed and successful log entries they are the same.
Hi @RohovDmytro!
Thank you for the information.
Around 25% of those Listen request fail with no particular reason, the Audit Logs just reports Fatal error. The app keeps working, but some user complain the data does not always load or update requests sometimes fail.
Could you expand the error log entry to see whatever information is available? There might be a clue hidden there.
Under the hood, Firestore should have a single Listen connection that is shared among all Listeners. If the connection fails, it will reconnect, which may be what you are seeing. The connection is kept alive to always receive updates. Listening should resume, but if the client has been offline for a little bit longer and some documents are no longer part of query, then the Firestore SDK will perform extra requests to resolve this cache inconsistency.
The log entry:
Stream closed with status: Status{code=INTERNAL, description=Internal error 05-12 17:12:42.179 15474 15688 W Firestore: Rst Stream, cause=null}.
Unfortunately cause=null leaves many open questions. Do any other platform provide more detail?
You may need to file a support issue to investigate the INTERNAL errors on your project. You can file a support ticket here:
https://firebase.google.com/support/troubleshooter/contact
Hey @RohovDmytro. 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!
Since there haven't been any recent updates here, I am going to close this issue.
@RohovDmytro 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.