So, we’ve run into a really strange behavior with the Web Messaging SDK (v4.3.1) specifically when the app is attempting to resume a session from a background state on Android (this is a scenario where the user has an existing session and receives a push notification to return to the chat). The issue is that the SDK seems to be failing the push token registration process during the handshake (it’s not a total crash but the session just won’t sync), and the user ends up staring at a blank chat window while the agent sees the visitor as “Online” (which is a nightmare for the UX since the visitor thinks the system is frozen). We’ve noticed that if the app is killed entirely and restarted from a cold boot, the token registers fine, but the background-to-foreground transition is where things fall apart (it’s almost as if the internal SDK state machine is stuck in a transition period and doesn’t realize the foreground activity has actually regained focus).
Here is the current setup:
- SDK Version: 4.3.1
- OS: Android 14 (API 34)
- Environment: Production Genesys Cloud org
- Integration: Open messaging integration
The logs are showing some weirdness during the session retrieval. We’ve tried to manually poll the message history to see if the session is even valid (using GET /api/v2/webmessaging/messages), and while the API returns the message list perfectly fine (meaning the session exists on the server side), the SDK isn’t updating the local UI state. It’s like there’s a disconnect between the API’s knowledge of the session and the SDK’s ability to bind the push token to that specific session ID once the app wakes up. We’ve double checked the manifest and the push service registration (which is handled via FCM), but the token doesn’t seem to be hitting the Genesys backend during these specific resume events.
[WebMessagingSDK] Error: Failed to register push token for session.
Status: 400 Bad Request
Message: Invalid session state for registration