So, we’ve run into a really strange edge case with the Web Messaging SDK (v4.2.1) specifically regarding how it’s handling background session resumption on iOS (this only seems to happen when the app is killed by the OS and then woken up by a push). The behavior is that when the visitor returns to the app via a deep link from a push notification, the session doesn’t seem to reconcile the existing push token correctly (which is odd because the token registration happened successfully during the initial handshake). It’s essentially acting like a new visitor in some contexts while maintaining the session ID in others, and the result is that the message history doesn’t populate when we call GET /api/v2/webmessaging/messages (even though the conversation ID is definitely valid).
The logs are showing a mismatch between the registration token stored on the device and what the SDK is sending during the re-authentication phase (it’s almost as if the internal state is being wiped during the transition from the background push handler to the foreground activity). We’ve tried manually clearing the cache and forcing a re-registration of the push token before the SDK initializes the session, but that just leads to a loop where the token is updated and then immediately overwritten by the cached version (a classic race condition, really). The app is running on iOS 17.4 and we’ve verified that the APNs certificates are all current and working for other services.
The weirdest part is that the interaction persists in the Genesys Cloud admin view, but the SDK just won’t bind to the existing thread. We’ve checked the integration settings via GET /api/v2/conversations/messaging/integrations/open to make sure no configuration changes were made on the backend, but everything looks standard there. It’s just this gap between the push trigger and the actual session restoration where the SDK seems to lose its grip on the visitor identity.