WebSocket disconnect (code 1006) immediately following a successful /api/v2/wfm/schedules/publish call. We are experiencing a critical issue where agents in our Chicago environment lose their WebRTC softphone connectivity the moment the weekly schedule publish completes on Tuesday mornings. The publish job runs at 6 AM CST via the API, and while the WFM module reports a 200 OK, the softphone clients for approximately 15% of the workforce drop their active WebSocket connections to the media servers. The browser console logs show a sudden closure event without a prior warning frame, followed by failed reconnection attempts that result in a 401 Unauthorized error for the next 30 seconds. This timing correlates perfectly with the schedule state change in Architect, suggesting that the underlying routing configuration update might be invalidating the active signaling tokens or forcing an unexpected media renegotiation that the Genesys Cloud WebRTC SDK (v2.4.1) is not handling gracefully. We have verified that the agents’ presence status updates correctly from ‘Available’ to their new scheduled state, but the audio path is severed during this transition. Restarting the browser or re-authenticating resolves the issue, but this causes significant downtime and missed interactions during the critical start-of-week ramp-up period. We are using the standard Architect flow for inbound voice queues with predictive routing enabled, and the issue does not occur when we manually update a single agent’s schedule outside of the bulk publish window. Has anyone encountered this specific race condition between the WFM publish endpoint and the WebRTC signaling layer? We need to know if there is a known delay or cache invalidation step we should implement in our automation script to prevent these forced disconnections, or if this is a bug in the current release of the softphone client that requires a different mitigation strategy.