No idea why this is happening, WebRTC connections drop immediately after the weekly schedule push completes.
Environment details: Genesys Cloud 24.5, Chrome 120, US-Central region. The issue manifests only for agents whose shifts start exactly at 09:00 CST. The Architect flow logs show a successful WebSocket connection, but the browser console throws a RTCPeerConnection iceconnectionstate change to failed within 500ms. This correlates perfectly with the WFM capacity update timestamp. Standard SIP softphones work fine. Are there known race conditions between the WFM API and the WebRTC signaling server during high-volume publishing events?
Have you tried isolating the WFM API call from the WebRTC signaling path? The timing correlation suggests a resource contention issue within the Genesys Cloud platform during the schedule publish window. When the /api/v2/wfm/scheduling/shift-requests endpoint is hit by a high-volume ServiceNow scheduled import, it can temporarily saturate the OAuth token refresh queue or the underlying database connection pool for that region. This latency often manifests as a timeout in the WebSocket handshake for concurrent WebRTC sessions, specifically those initializing at the exact moment of the WFM batch job.
The browser console error iceconnectionstate changing to failed within 500ms is not typically a network ICE failure but rather a signaling interruption. The platform fails to push the SDP answer because the internal service is locked.
To mitigate this, adjust the ServiceNow scheduled job to run with a 15-minute offset from the start of the shift. If the shift starts at 09:00 CST, schedule the WFM data pull for 09:15 CST. Additionally, implement exponential backoff in the ServiceNow script include that handles the Genesys Cloud API calls.
// Example ServiceNow backoff logic
function fetchWFMData() {
var response = sn_ws.RESTMessageV2.call('genesys-wfm-endpoint');
if (response.getStatusCode() == 429 || response.getStatusCode() == 503) {
// Wait 5 seconds before retrying
gs.sleep(5000);
fetchWFMData(); // Recursive retry
}
return response;
}
Also, verify the WebSocket keep-alive interval in the Genesys Cloud admin settings. Increasing this from the default 20 seconds to 30 seconds can provide a larger buffer for these transient platform hiccups. Check the Genesys Cloud System Health dashboard during the 09:00 CST window to see if there are any reported API latency spikes in the US-Central region. If the issue persists, capture the WebSocket trace logs from the agent’s browser and correlate the timestamps with the WFM API execution logs in ServiceNow.