Running into a weird bug with implementing WebSocket reconnection logic for the Notification API in Node.js. My current implementation closes the connection gracefully but fails to re-establish the subscription context after a network blip, resulting in dropped event streams. Is there a specific header or token refresh mechanism required in the reconnection handshake to maintain state? The SDK documentation is sparse on this edge case.
The problem is that the initial platformClient.Notifications.createSubscription call establishes the scope, but your reconnection logic likely skips this step or uses an expired token. You need to re-invoke createSubscription with the original body parameters on every socket reconnect event, ensuring the Authorization header uses a fresh Bearer token from your platformClient.auth.getAccessToken() cache before calling ws.connect().
How I usually solve this is by wrapping the subscription logic in a dedicated async method. The documentation states “subscriptions are stateful and must be re-established after disconnection.” In my .NET integrations, I ensure the token is refreshed before calling createSubscription again.
Here is a C# pattern using PureCloudPlatformClientV2:
public async Task EnsureSubscriptionAsync()
{
var body = new CreateSubscriptionRequest
{
Version = 2,
Resources = new List<string> { "routing:queues:events" }
};
await _platformClient.Auth.RefreshAccessTokenAsync();
var response = await _platformClient.Notifications.CreateSubscriptionAsync(body);
_wsClient = new WebSocketClient(response.WebSocketUrl);
_wsClient.Opened += OnConnected;
_wsClient.Error += OnError;
await _wsClient.ConnectAsync();
}
You must handle the OnError event to trigger EnsureSubscriptionAsync recursively. Do not skip the CreateSubscription call on reconnect. The previous answer missed that the token expiration is the root cause, not just the socket state. Use HttpClient patterns to manage the token lifecycle separately from the WebSocket loop.
I think the core issue is treating the WebSocket connection as stateless when the Genesys Cloud Notification API strictly requires re-establishing the subscription context via platformClient.Notifications.createSubscription upon every reconnect event. Relying on implicit session persistence is a common pitfall in Node.js implementations. You must ensure your reconnection logic explicitly calls createSubscription with the original body parameters, but crucially, you must inject a fresh Bearer token from platformClient.auth.getAccessToken() into the Authorization header. Using an expired token causes the server to reject the handshake, leading to the dropped streams you described. Additionally, verify that your ws library configuration handles the upgrade request correctly, as misconfigured headers here will silently fail. I use a dedicated async wrapper to handle token refresh before the socket reconnects, ensuring the scope remains valid for the routing:queue:view permissions required for your event stream.
You need to verify the token refresh mechanism within your reconnection loop. Cause: The initial subscription context expires if the Bearer token is not refreshed before re-invoking createSubscription. Solution: Ensure your Node.js logic calls platformClient.auth.getAccessToken() immediately before reconstructing the subscription payload, preventing state loss during network blips.