Ran into a weird issue today with the Genesys Cloud Notification API when streaming analytics events to a Kafka topic via a Node.js consumer. Subscribing to analytics:queueMetrics:realtime through /api/v2/analytics/queueMetrics/realtime with a long-polling fallback causes nested intervalData arrays to vanish after the third message. The ws client holds a connection to wss://api.mypurecloud.com/api/v2/analytics/queueMetrics/realtime?topic=analytics:queueMetrics:realtime&interval=60, but unexpected drops trigger an HTTP 429 Too Many Requests on the REST fallback. OAuth2 Bearer rotation works fine, refreshing every fifty-five minutes via client credentials. Deserialization breaks inside the OpenAPI-generated TypeScript client when a custom ApiResponse transformer maps raw JSON to strict Zod schemas. Generator flags are set to additionalProperties: false and strict: true, forcing a type mismatch whenever the GC server emits sparse payloads. Does the notification engine enforce a hard message size cap that truncates JSON before ws parses it, or does the intervalData schema definition in the current spec simply allow optional nesting that breaks strict parsing? Patching the generator template to tolerate undefined arrays might be cleaner than rewriting the consumer backoff logic. Kafka batching works perfectly with complete payloads, yet truncation shatters the aggregation pipeline. Initialization and transformer logic sit below.
const ws = new WebSocket(url, { headers: { Authorization: `Bearer ${token}` } });
ws.on('message', (data) => {
const events = JSON.parse(data.toString());
events.forEach((evt: any) => {
if (evt.type === 'analytics:queueMetrics:realtime') {
producer.send({ topic: 'gc-analytics-stream', messages: [{ value: JSON.stringify(evt.data) }] });
}
});
});