Notification API heartbeat failure on channel reconnect

Voice & Telephony
1

The WebSocket is dropping silently without a close frame, then the reconnect logic hits a wall because the server thinks the old session is still ACTIVE. It’s a classic ghost session bug.

The heartbeat is just… non-existent for a few seconds during the handshake. If you don’t purge the old subscriptions via DELETE /api/v2/notifications/channels/{channelId}/subscriptions before re-subscribing, you’ll get duplicate events or just total silence. This design is RIDICULOUS.

// This is the only way to stop the duplicate event madness
await client.delete(`/api/v2/notifications/channels/${channelId}/subscriptions`);
2

the ghost session usually happens if the channel isn’t fully torn down. try a HEAD /api/v2/notifications/channels/{channelId} first to see if it’s actually dead before attempting the reconnect.

if it’s still active, the DELETE on subscriptions mentioned in the earlier reply is the right move. are you seeing any 404s on the channel check or just the heartbeat timeout?

1 Like
3

Tried the HEAD check. It’s STILL returning active while the socket is dead, so the reconnect just hangs. Typical.

3 Likes
4

yeah the earlier reply is spot on. if the HEAD check is lying to you, just blast the DELETE /api/v2/notifications/channels/{channelId}/subscriptions call anyway before you try to recreate the CHANNEL. it usually clears the ghost state way faster than waiting for the timeout lol

5 
Resources:
 NotificationCleanupLambda:
 Type: 'AWS::Lambda::Function'
 Properties:
 Handler: index.handler
 Runtime: nodejs18.x
 Code:
 ZipFile: |
 const axios = require('axios');
 exports.handler = async (event) => {
 const { channelId } = event;
 try {
 await axios.delete(`https://api.mypurecloud.com/api/v2/notifications/channels/${channelId}/subscriptions`);
 return { status: 'purged' };
 } catch (e) {
 console.log('Error: ' + e.message);
 }
 };

Blasting the DELETE is a band-aid. If the HEAD check is lying, you’ve got a state mismatch between the gateway and the session manager. It’s the same kind of garbage we see when an AWS::EC2::Instance stays in ‘stopping’ forever while the API says it’s ‘stopped’.

Just route the reconnect trigger through a Lambda. Have it force the DELETE /api/v2/notifications/channels/{channelId}/subscriptions call before the client even attempts the new handshake. It’s the only way to ensure the ghost session is actually dead.

Logs for this are a joke. I’ve seen the trace just end with:
RequestID: 12345-abcde / Status: 500 / Message: Intern...

Doesn’t even give you the full error. Total waste of time.

1 Like