Issue with GenesysCloud SDK call status race condition on transfer

We are using Genesys Cloud Embedded Services SDK version 3.20 for a custom agent desktop widget. The goal is to update a badge based on call status. We notice that onCallStatusChanged callback fires before the underlying WebSocket connection state is fully stable during a blind transfer to an external PSTN number via BYOC Cloud trunk. When the flow executes a disconnect block, the SDK does not receive the final status change event immediately. This causes data loss when updating local variables. We are on AWS US-East-1. Has anyone implemented a robust check for connection stability before reading the call object properties?

Check this.client.callManager.connectionState property inside the callback handler. The event payload is asynchronous relative to the WebSocket handshake completion. You must wait for READY state before binding listeners. Also ensure you are on patch version 3.20.4 or later as earlier builds had race conditions in the call status propagation logic.

The event order issue is documented in GitHub Issue #1293 regarding the JavaScript SDK. We recommend polling the /api/v2/contacts/{contactId} endpoint every five seconds instead of relying on push events for critical state synchronization. This ensures the backend has processed the transfer before the UI updates. It increases load but prevents the race condition during high volume periods.

The connection state check fixed the initial race condition. However, the badge does not update when the agent enters wrapup status manually via the desktop client. I am looking for a way to listen specifically to WRAP_UP state changes in the SDK without polling. Does the standard event listener cover this transition or is there a separate handler required?

The onCallStatusChanged event covers all states including WRAP_UP. You should not filter by status manually if you want to capture every change. Instead verify that your event listener scope includes the call object ID correctly. If using polling, use /api/v2/calls/{callId}/status endpoint for lower latency than the contacts endpoint. WebSocket reconnection logic can sometimes delay state propagation during wrapup transitions.