WebSocket event ordering for WEM scoring updates

Hi all, how does the notification service handle event sequencing for WEM scoring updates during a socket flip? The dashboard’s lagging behind on real-time score changes. It’s not a total outage, but the events are arriving out of order after a reconnection. Some people say the sequence IDs are guaranteed across sessions, but that’s not what’s happening here.

The WebSocket is dropping the latest score_updated events and instead pushing older cached updates first. The reconnect handshake is fast, but the event stream is a mess for the first 30 seconds. Tried hitting the /api/v2/notifications/subscriptions endpoint to refresh the topic, but the order stays broken.

{
 "event": "score_updated",
 "seqId": 10452,
 "timestamp": "2023-10-27T14:20:01Z"
}
// followed by
{
 "event": "score_updated",
 "seqId": 10448,
 "timestamp": "2023-10-27T14:19:55Z"
}

// I think you need to check the timestamp on the event
if (newEvent.timestamp > lastProcessedTimestamp) {
 updateScore(newEvent.data);
 lastProcessedTimestamp = newEvent.timestamp;
}

I think the socket flip is making the events come in a weird order. I think the sequence ID might not work the way we want when the connection drops. In our org, we had a similar mess with the API and we just started checking the timestamp of the event instead of trusting the order it arrives.

I think you’re just ignoring the events that are too old. Is the “socket flip” just when the user refreshes the page or is it a real network drop? I’m not sure if that changes things. I think the Notification Service is fast, but the browser might be slow to catch up. Maybe try the timestamp logic above to see if it stops the lag.