Hi all,

The event ordering is behaving inconsistently during high-volume bursts in our production environment. We’re using v2 of the API and the current WebSocket setup is failing to maintain the correct sequence when the connection drops. Reconnection happens, but some notifications seem to be missing or arriving out of order.

The logic involves calling GET /api/v2/notifications/channels to verify the active session before attempting to refresh the topic list. We’ve tried using PUT /api/v2/notifications/channels/{channelId}/subscriptions to reset the subscriptions, but the event stream still feels fragmented. Performance is dropping when the volume peaks.

The logs show a generic communication error during the handshake, but it’s not clear why the sequence IDs aren’t aligning. It’s creating a drift in the real-time dashboard.

// Attempting to refresh subscriptions to stabilize the stream
await platformClient.notifications.setSubscriptions(channelId, [
 {
 topic: 'v2.detail.events.conversation',
 qos: 'DEFAULT'
 }
]);

The system is just not catching up.

• WebSockets don’t guarantee delivery during drops. Use GET /api/v2/notifications/channels/{channelId}/subscriptions to verify state on reconnect.
• Poll for missed events via the analytics or conversation endpoints to fill gaps. Seen a few community posts where people just rely on the socket and lose data during bursts.

We have implemented the subscription verification as suggested. However, the event sequence remains inconsistent during reconnection. We are still observing gaps in the notification stream, specifically where timestamps overlap across the resubscription boundary.

i think the earlier reply is correct. we’ve found similar gaps at 2024-07-10T09:15:00Z. sorry for newbie question, but maybe check if channelId is still valid first? use HEAD /api/v2/notifications/channels/{channelId} before resubscribe. it’s possible channel is expired.

log:
{“status”: 404, “error”: “Not Found”, “timestamp”: “2024-07-10T09:16:02Z”}

ok so, just a heads up on the resubscribe approach. If the logic just blindly calls POST /api/v2/notifications/channels/{channelId}/subscriptions on every reconnect, you might end up with dupes or weird race conditions in the event stream. It’s a bit of a gotcha if the channel is still technically active but the socket is just flaky.

Better to check what’s already there first so the config stays clean. Something like this logic:

on reconnect

check current_subs = GET /api/v2/notifications/channels/{channelId}/subscriptions

desired_subs = [list of topics needed]

missing_subs = desired_subs MINUS current_subs

if missing_subs is not empty:

POST /api/v2/notifications/channels/{channelId}/subscriptions (only missing_subs)

That way the prod env doesn’t get bogged down with redundant subs. Small thing, but it helps with perf when you’ve got high-volume bursts. Still figuring out the best way to handle the actual gap filling though.