V9.0 - RNFB messaging().getInitialNotification() not working with Notification Service Extension

[james-cohen]

Since the latest update, the .getInitialNotification() method provided by React Native Firebase now works again, which is great as we use it for redirecting immediately to deeplinks on launch.

However, if the notification is modified by the Notification Service Extension (as found here), .getInitialNotification now returns null, as does the notifee version of the method. If we set mutable-content to 0, so the NSE is no longer triggered, .getInitialNotification() returns the notification again. We have followed the guide exactly and are only using the Notifee service helper without any further modification.

There is a related issue in the RNFB repo that specifies that a property gcm.message_id is required for the notification to be intercepted. Could that be a similar issue here? And if so, what would be the way to modify the NSE to include this value?

Payload being submitted from APS (this is correctly intercepted by the NSE and generates a conversation style message):

{
    "aps": {
        "alert": {
            "title": "Test User",
            "body": "How are you?"
        },
        "mutable-content": 1,
        "badge": 1,
        "content-available": 1
    },
    "data": {
        "type": "NEW_MESSAGE",
        "deeplink": "https://deeplink.com/test"
    },
    "gcm.message_id": "test1234",
    "notifee_options": {
        "data": {
            "type": "NEW_MESSAGE",
            "deeplink": "https://deeplink.com/test"
        },
        "ios": {
            "communicationInfo": {
                "conversationId": "conversation1234",
                "sender": {
                    "id": "testUser123",
                    "avatar": "https://image-url.com/test,
                    "displayName": "Test User"
                }
            },
            "badgeCount": 1
        }
    }
}

[mikehardy]

Hi there! The only change I can think of that would affect this is possibly #985 - but that is only because I expect you just updated from the previous latest version to the current latest version, that is, from 7.8.2 to 9.0.0 and I have constrained the search for what could cause this to the diff between those versions

(https://github.com/invertase/notifee/releases)

But you did not specify anything about what versions you started with and are using now so I'm unsure

Additionally, I'm not sure in the absence of a minimal reproducible example and description of app states what's specifically happening.

I suspect you may be running in to the deprecation (on iOS currently but intended on Android as well...) of getInitialNotification for any notifications handled by the Notifee Notification Service Extension

#616 (comment)

It appears - on iOS at least for now - that you need to listen for the PRESS event received by the onForegroundEvent event handler

This was the most recent report of success on all platforms + all states, but perhaps you were doing that already ?

#616 (comment)

[mikehardy]

(note, since you have the reproducible scenario - if you were on v7.8.2 and went to v9, then attempting a revert of that specific code change from PR #985 and re-testing will pinpoint the problem exactly, at which point determining how to fix it without re-breaking what 985 attempted to fix becomes the next task - and the best way to complete it is to propose a PR as this is a pretty complicated scenario that I don't have an app to test with)

[james-cohen]

Thanks for the detailed response. We did indeed upgrade from 7.8.2 but it wasn't working then either - that was expected as found in the release notes from 7.0.0 that it would no longer trigger.

The PR you highlighted (#985) is actually the one that allowed .getInitialNotification to start working at all - I should have referred to it in my initial ticket. My question is why does it now work again for remote notifications that have not been modified, but does not trigger when they have been modified by the NSE?

[github-actions]

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

[james-cohen]

Happy to close this - this was a misunderstanding on my part on how notification detection logic works between Notifee / RNFB