Dealing with a very strange bug here with the Genesys Cloud WebSocket analytics stream when piping events to a local Kafka topic via Node.js. The connection terminates unexpectedly with a 1006 code after approximately 5000 messages, despite the keepAlive interval being correctly configured.
Environment details:
- Node.js 18.17 LTS
ws library v8.14- Genesys Cloud
analytics/events endpoint
- Kafka broker on port 9092
ws.on('message', (data) => {
kafkaProducer.send({
topic: 'genesys-analytics',
messages: [{ value: data.toString() }]
});
});
Does the platform enforce a specific message rate or payload size that triggers this silent disconnect?
It depends, but generally… the 1006 code usually indicates the server closed the connection without a proper close frame, which often happens when the client stops sending pings or fails to handle the pong event correctly in the ws library. I have seen this exact issue in ServiceNow integrations where the event loop gets blocked by heavy database writes, causing the WebSocket heartbeat to timeout. You need to ensure your ping/pong interval is shorter than the server’s idle timeout, typically 30 seconds. Here is a robust setup that handles backpressure and keeps the connection alive while writing to Kafka:
const WebSocket = require('ws');
const ws = new WebSocket('wss://api.mypurecloud.com/api/v2/analytics/events', {
headers: { 'Authorization': `Bearer ${token}` }
});
ws.on('open', () => {
setInterval(() => {
if (ws.readyState === WebSocket.OPEN) {
ws.ping();
}
}, 25000);
});
ws.on('pong', () => {
// Connection is alive
});
ws.on('message', async (data) => {
try {
await kafkaProducer.send({ topic: 'gc-events', messages: [{ value: data }] });
} catch (err) {
console.error('Kafka write failed', err);
}
});
Verify that your keepAlive interval in the subscription payload matches your client-side ping interval to prevent the platform from dropping idle connections.