PushError$MalformedMessage: parsing encrypted message failed: java.util.NoSuchElementException: Key body is missing in the map.

[pocmo]

https://sentry.prod.mozaws.net/operations/firefox-beta/issues/7662509/

PushError$MalformedMessage: parsing encrypted message failed: java.util.NoSuchElementException: Key body is missing in the map.
    at mozilla.components.lib.push.firebase.AbstractFirebasePushService.onMessageReceived(AbstractFirebasePushService.kt:14)
    at org.mozilla.fenix.components.FirebasePushService.onMessageReceived(FirebasePushService.kt:1)
    at com.google.firebase.messaging.FirebaseMessagingService.zzd
    at com.google.firebase.iid.zzc.run
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
...
(3 additional frame(s) were not displayed)

[INFO] parsing encrypted message failed: java.util.NoSuchElementException: Key body is missing in the map.

┆Issue is synchronized with this Jira Task

[pocmo]

@jonalmeida Saw that happen in a Beta migration build. Since it is "info" level I am not sure if we need to act on it?

[pocmo]

Sentry issue: FENIX-FENNEC-BETA-2A

[jonalmeida]

Yes, this is the same as I mentioned here: #6418 (comment)

[grigoryk]

@jonalmeida seeing a lot of this in regular Fenix builds (https://sentry.prod.mozaws.net/operations/firefox-nightly/issues/7577599/) - are you sure this is normal? Seems like a mismatch of expectations to me.

[jonalmeida]

The errors say we received a valid AutoPush message (because it containers the 'chid' value) but we don't have a 'body'. We drop the messages at the push service level since we're not able to decrypt a message without a body.

I can verify this with @jrconlin but I believe there's not much we can do with a message that does not have these three values, the other two are optional.

If it was an optional value, following the code through to the native layer, we would hit this call which would lead to a TranscodingError when we try to base64 decode it first.

In the Fenix 4.1 release, we have WebPush enabled so iirc, there are WebPush implementations in the wild that do not follow the standard, but that might just be one of many possibilities.

I'll double-check this on Monday.

[jonalmeida]

I can verify this with @jrconlin but I believe there's not much we can do with a message that does not have these three values, the other two are optional.

Looking at the AutoPush FCM router, I think my memory is accurate. We need to always have chid, body, and con values to continue with decryption: https://github.com/mozilla-services/autopush/blob/master/autopush/router/fcm.py#L174-L182

[grigoryk]

Why are we getting push messages, from autopush, without body?

[jrconlin]

So it turns out that there is the potential for an empty "tickle" push message. There are a few use cases for these (including encryption testing, since they can be delivered without any ECE encryption, and thus removing one thorny variable from the mix). The function of these "tickle" messages with the app is basically an empty "poke" event.

This message should have no encryption header info, nor any body. I believe this could be resolved by having either the Kotlin or the lower rust code check to see if there is no header data and no body and return an empty binary array.

[st3fan]

At the least we should not report an info message and just ignore it otherwise this will go crazy on production.

[jonalmeida]

This should be fixed now. I'm monitoring sentry to see if the crashes go down when we have a new build for fenix.

[jonalmeida]

Looking at our crashes, the MalformedMessage no longer shows up in large amounts on Fenix nightly. Closing this as fixed with the changes that landed.

We have also removed the nightly-only flag from WebPush integration: mozilla-mobile/fenix#9338