So, we’ve run into a really strange behavior with the Web Messaging SDK (v4.3.1) specifically when handling deep links that are supposed to resume a session while the app is in the background (this is a critical flow for our push notifications where the user clicks a link and we expect them to land right back in the active chat). The issue is that the SDK seems to be initializing a brand new session instead of attaching to the existing one (which basically wipes out the visitor’s context and leaves the agent staring at a new interaction), and it’s happening almost exclusively on Android 14 devices when the activity stack is cleared.
The logic we’ve implemented follows the standard registration flow (which usually works fine during a fresh boot), but when the deep link triggers the intent, the SDK doesn’t seem to recognize the existing session token (even though it’s still stored in the local cache). It’s like the SDK forgets the session state the moment the app transitions from the background to the foreground via a deep link (this is frustrating because the push token registration is still active), and we’re seeing the app trigger a new session creation call. We tried to verify if the messages were still there by hitting the backend via GET /api/v2/webmessaging/messages using the old session ID, and the messages are definitely there (which proves the session hasn’t expired on the server side), but the SDK just won’t bind to it.
The logs aren’t giving us much to go on (it’s mostly just generic initialization noise), but the timing is always the same: the app wakes up, the deep link is parsed, and then the SDK fires off a new session request. We’ve tried manually clearing the cache and forcing a re-auth (which is a bit of a sledgehammer approach), but that doesn’t solve the underlying problem of the session mismatch.
[WebMessagingSDK] Initializing session...
[WebMessagingSDK] No active session found in local storage.
[WebMessagingSDK] Creating new session: session_id=abc-123-xyz