Notification API - WebSocket disconnects after Architect update

Is anyone else seeing weird disconnects with the notification API WebSocket stream after the recent architect update? We’ve got a supervisor dashboard built on Vue 3, pulling queue stats via the real-time conversation details stream. It’s fine for a few hours, then the WebSocket just…drops.

It’s not a 400 or 500 error, just a clean disconnect. The connection is re-established automatically by the client (using the recommended exponential backoff strategy) but the charts flicker obviously. Happens multiple times a day now. Before this architect push it was rock solid.

The architect flow itself wasn’t changed in a way that should affect the notification API. It’s a pretty simple setup - IVR, transfer to a skill, then a wrap-up. We checked for any new data actions triggered in the flow, nothing obvious there.

Logs on the server side are empty. Absolutely nothing is written when the disconnect happens - which is infuriating. No errors, no warnings, just silence. The client-side console shows this:

WebSocket connection to wss://genesyscloud.com/notification-api/v2/events disconnected

We’re on v2024.1.2 now. The SDK version is current - the latest available on npm. We’ve tried increasing the heartbeat interval in the WebSocket options but it didn’t make a difference.

It feels like something in the architect update is causing a brief spike in load somewhere that’s killing the WebSocket connections. Given that the logs are empty, a full investigation is going to take days. Is there a quick way to work around this? Maybe a different endpoint we can tap into for queue stats? Doesn’t need to be real-time, even a 30-second delay would be preferable to the constant flickering. A temporary fix is better than spending a week tracking down a phantom load issue.

Right, WebSocket disconnects after an architect update - sounds like fun. Honestly, it’s almost always a throttling issue, imo. The conversation details endpoints are…sensitive.

You’re pulling queue stats, which means you’re hitting the conversation details stream repeatedly. The GC rate limits aren’t exactly advertised - they’re more…discovered through pain, tbh. Try adding a retry mechanism with exponential backoff on the client-side, but also - and this is key - implement a jitter factor. Don’t just retry every 5 seconds, add a random delay up to 5 seconds. Like, Math.random() * 5000. It helps avoid synchronized retries hammering the API.

Also, check your data action configurations - iirc - if you’re using those to push data into the stream, make sure they aren’t looping. We had a situation where a badly configured data action was effectively DDoS’ing our own real-time stream, causing exactly this behavior. Inspect the execution history of any relevant data actions.

The WebSocket connection itself - the ws:// or wss:// URL - shouldn’t change with an architect update, so that’s less likely the issue. Worth a shot, though.