Embeddable Framework - Realtime Stats Not Updating After Agent State Change

Hi all,

We’re building a custom agent desktop using the embeddable framework - v3.5.0, and the client app SDK - v1.43.0. It’s… not updating the real-time stats properly when an agent changes state. Specifically, when an agent goes from ‘Available’ to ‘Not Ready’, the stats component freezes. The data was updating before the state change, then… nothing.

The component uses sdk.agentDesktop.getRealtimeStats() to pull the stats. We’re polling every 5 seconds, which seems reasonable? The UI shows the correct state transition - the agent’s status badge updates fine - but the stats panel shows old values. It doesn’t error, it just…stops updating. It’s weird.

I’ve been looking at the event stream - the AGENT_STATE_CHANGE event fires as expected. I’m subscribing to the event, logging the new state, and then calling sdk.agentDesktop.getRealtimeStats(). The console logs show the state change, but the getRealtimeStats() call after seems to return cached data. Or no data. Hard to say.

const handleAgentStateChange = (event: AgentStateChangeEventArgs) => {
 console.log("Agent state changed to:", event.agentState);
 getStats();
};

const getStats = async () => {
 try {
 const stats = await sdk.agentDesktop.getRealtimeStats();
 setStatsData(stats); // This is a React state update
 } catch (error) {
 console.error("Error getting stats:", error);
 }
};

The error is… not an error, exactly. It’s just stale data. I thought maybe there was some caching issue within the embeddable framework, but I can’t find anything about that in the docs. I tried clearing the browser cache, didn’t help. I’ve checked the permissions - the agent role has all the necessary permissions for real-time stats. We are on Genesys Cloud, of course.

Also, I’m not sure if it’s connected, but sometimes I see this in the browser console around the same time: [genesys-cloud-sdk-client-app] WebSocket connection closed - code: 1006, reason:. Is that normal? Or is it…a disconnect? It reconnects quickly, but still. I think it might be a race condition.

The stats are not updating at all. It’s just… stuck. I’m thinking the AGENT_STATE_CHANGE event might be causing some kind of internal re-initialization, but I can’t find any documentation about that.

Can you confirm the polling interval is not conflicting with the agent state update frequency? We are preparing for the SOC2 audit and need to validate the data consistency. Is the SDK configured to listen for state change events, or only relying on the poll?

Are you subscribing to the agentDesktop.onAgentStateChange event to polling? We’ve found the polling interval can be… unreliable if the underlying state isn’t pushed through the event stream. It’s similar to the issues discussed in the Data Action timeout thread - if you don’t listen for the event, you’re constantly asking for a state that might have already changed.

The SDK documentation suggests it’s best practice to combine both, but we’re still trying to understand how everything fits together. We had similar problems with the WebSocket payload limits a few weeks back, and we had to strip the skill level matrices from the initial routing updates. It’s a bit like that, but for state changes.

To ensure consistency, you can try this:

sdk.agentDesktop.onAgentStateChange(state => {
 // Update stats immediately when state changes
 getRealtimeStatsAndRender();
});

function getRealtimeStatsAndRender() {
 sdk.agentDesktop.getRealtimeStats()
 .then(stats => {
 // Render stats with the new data
 })
 .catch(error => {
 console.error("Error getting stats:", error);
 });
}

// Continue polling every 5 seconds as a fallback
setInterval(getRealtimeStatsAndRender, 5000);

This should ensure your stats component updates immediately when an agent changes state via the event, and the polling provides a fallback for any missed updates. It’s worth checking the event payload to confirm it includes all the necessary state information.