Event is not sent when the android app is in the background - firebase messaging

[Rafazor]

I'm trying to track when a notification is received. I'm using @react-native-firebase/messaging.

Current implementation:

 messaging().setBackgroundMessageHandler(async (remoteMessage) => {
    await track("notification.received", {
          notification_id: remoteMessage.messageId,
          title: remoteMessage.notification?.title,
        });
});

setBackgroundMessageHandler is called every time a notification is received, but the track event is sent only when the app is in the foreground and not in the background. Other API calls are working as expected when they are called from setBackgroundMessageHandler.

• @segment/analytics-react-native": "^2.13.5"
• "react-native": "0.70.1",
• "@react-native-firebase/messaging": "^17.4.3",

Steps to reproduce
Put the app in the background and generate a notification.

Expected behavior
The event (notification.received) is sent to Segment.

Actual behavior
The event is not sent when a notification is received, it's only sent later on when the app is back in the foreground.

[oscb]

Last I knew RN completely stopped execution of JS as soon as the app goes into the background in Android (not for iOS). Has this changed?

Will have to retest to verify.

[mattlennon3]

We're seeing the same behaviour. Very occasionally we get some result, but it's less than 10% of the time.

JS will run in the background for firebase messaging as it uses registerHeadlessTask. See the headless JS docs here.

Firebase messaging uses this here and the entrypoint in the same file here

We're using these packages:

"@react-native-firebase/app": "15.7.1",
"@react-native-firebase/analytics": "15.7.1",
"@segment/analytics-react-native": "2.18.0",
"@segment/analytics-react-native-plugin-firebase": "0.4.1",

[mattlennon3]

@Rafazor do you still have this problem? I'm curious about this line:

The event is not sent when a notification is received, it's only sent later on when the app is back in the foreground.

This would be acceptable to us, but we don't see this. Are you doing some storage/queueing of the event to be sent later?

EDIT:
While doing some testing today, I saw some events from last Friday, meaning something is being stored by segment..

[Rafazor]

@mattlennon3 @oscb Thank you for your time and answers. In the meantime, I switched companies and don't have access to the codebase to confirm that the issue is still present. :)

Our goal was to improve notification convergence, and we needed a way to track the number of notifications received and after that from that number of notification.received events we wanted to track how many notifications were used to open the app so the current behavior on Android ("The event is not sent when a notification is received, it's only sent later on when the app is back in the foreground.") was not super helpful because a lot of times you receive a notification but you don't actually check it.

[mattlennon3]

Thanks for the response @Rafazor. That was our thinking too, the ratio of sent:received:pressed.
Our pressed tracking works, but only because it opens the app to handle the notification press.
I think sent:pressed is not as useful to compare.

I reviewed some of the Segment code. There is some storage of events and a Timeline class, but I couldn't see anything of concern. I think it'll need to be set up locally and checking etc. I can't give the time unfortunately.