Building a custom Node.js client for the Genesys Cloud Notification API using WebSocket. The connection to wss://api-us-east-1.genesys.cloud/api/v2/platform/sessions works fine initially, but the reconnection logic is failing when the server pushes a close frame with code 1012 (Service Restart).
The @genesyscloud/sdk-js internal handling isn’t exposed cleanly for custom retry backoff, so I’m managing the lifecycle manually. The issue is that after a 1012 close, the next connect() attempt hangs or gets a 401 Unauthorized, even though the OAuth token is valid. It seems like the session state on the server side isn’t cleaning up properly before the new connection attempt.
Here’s the relevant snippet:
const WebSocket = require('ws');
async function connectWS() {
const token = await getValidToken();
const ws = new WebSocket('wss://api-us-east-1.genesys.cloud/api/v2/platform/sessions', {
headers: { 'Authorization': `Bearer ${token}` }
});
ws.on('close', (code, reason) => {
console.log(`Closed: ${code} - ${reason}`);
if (code === 1012) {
console.log('Service restart detected, reconnecting...');
// Exponential backoff
setTimeout(() => connectWS(), 5000);
}
});
ws.on('error', (err) => {
console.error('WebSocket error:', err.message);
});
}
The first connect succeeds. After a forced server restart simulation, the close event fires with 1012. The recursive connectWS() call gets the token, creates a new WS instance, but never emits ‘open’. The error handler doesn’t fire immediately. It just hangs.
Is there a specific header or query param I’m missing for reconnection? Or is the 1012 code indicating a different state that requires a full session teardown? The docs mention “clean” closes, but 1012 feels like an edge case. No useful logs on the server side either. Just silent failures.
Any insights on how the official SDK handles this specific 1012 scenario? I’ve checked the source, but the abstraction layers are deep. Looking for a workaround or a confirmation that this is a known issue with the Notification API endpoints.