Stuck on a recurring issue where the WebRTC softphone handshake fails with a 408 Request Timeout when the WFM module attempts to publish schedules for queues exceeding 500 agents. The environment is Genesys Cloud 2024.3 (US-East-1) with a custom BYOC edge.
The failure happens consistently during the weekly schedule publish window for our Chicago team (America/Chicago). Agents report that their softphones disconnect or fail to register momentarily, which disrupts shift swap validation workflows that rely on real-time adherence data.
Error: WebSocket connection failed. Code: 408 Request Timeout. Reason: The server did not receive a complete request message in time.
I have verified that the SIP trunk registration remains stable, so this appears isolated to the WebRTC signaling path during high-concurrency API calls. The /api/v2/wfm/schedules/publish endpoint returns a 200 OK, but the client-side WebRTC logs show the handshake drop immediately after the publish job initiates.
Has anyone experienced similar latency spikes between the WFM publish event and the WebRTC re-registration? We are considering throttling the publish batch size, but want to understand if this is a known limitation of the current SDK version or an Architect flow configuration issue.