Web Messaging SDK - Push Notification Registration

General Discussion
1

So, we’re running into something odd with push notification registration via the Web Messaging SDK - specifically, it looks like token updates aren’t always propagating correctly to Genesys Cloud, and it’s happening only on Android (which, naturally, makes things more fun). From what I’ve seen, it’s not a consistent failure, maybe one in every ten or so registrations exhibits this behavior, and it’s proving difficult to reproduce reliably in a test environment (it seems to need actual user interaction over a prolonged period, which is a pain). The SDK version we’re using is the latest as of last week - 4.2.1 - and we’re targeting API v2 for everything, obviously.

The flow is pretty standard - the user grants permission, we call sdk.registerPushNotifications() with the obtained token (from the FCM service, verified locally, so that’s not the immediate issue), and we receive a success callback. However, when we subsequently check the registered device tokens through the Genesys Cloud REST API - hitting /api/v2/users/{userId}/pushnotifications - the new token isn’t always present. Sometimes it updates as expected, sometimes it just… doesn’t. We’ve checked the console logs within the SDK itself, and there are no errors reported during the registerPushNotifications() call, which is where the initial confusion lies (it’s passing back success, but the token isn’t always showing up).

It’s possible there’s a race condition somewhere within the SDK, perhaps related to background session handling (it’s something we’ve struggled with previously, although we thought we’d ironed it out), or maybe a limitation in how frequently the SDK attempts to re-register the token (we’ve increased the polling interval, but haven’t seen much improvement). I’ve also considered the possibility that the user ID isn’t being resolved correctly on the server side, leading to the token being registered against a different user account (though the logs don’t suggest that’s the case, it’s still worth exploring). Just a hunch, but maybe there’s a subtle difference in the request body structure that’s causing the API to reject the update, but only intermittently. The Android manifest permissions are all correct, and the FCM configuration is verified.

2

ok so the android token update issue usually stems from the sdk’s handling of service workers → the platform api expects a consistent registration id. it’s possible the sdk isn’t correctly propagating the new token when the service worker lifecycle restarts, especially on android’s background execution limitations.

the web messaging api v2 endpoint /api/v2/webmessaging/registrations requires a valid registrationId and pushToken. you’ll need to confirm the sdk is sending the new token alongside the original id after a service worker refresh. a quick check is to inspect the network requests in your android developer tools when the token should be updating - see if the registration id is present in the payload.

1 Like
3

yes, i think the service worker is a problem too. i am looking at the logs, and i see sometimes the registrationId is changing, then the push is not coming.

from what i see, maybe the SDK is not sending the registrationId with every request? the /api/v2/webmessaging/registrations endpoint need this always, like a traceroute hop, not just when is new. i have try to get the logs with more details, but is very big.

{
 "registrationId": "old-id-123",
 "pushToken": "token-abc"
}

then after some time

{
 "pushToken": "token-def"
}

missing registrationId?

is this normal? is there a way to force the SDK to send this always? we are on Genesys Cloud, version 23.11.

1 Like