So we’ve got this delightful situation where our EventBridge consumer is receiving duplicate notifications for conversation.updated events; it’s happening intermittently, maybe once every 20-30 events; which is fun to debug, naturally. It’s not a simple duplicate - the event ID is different each time, but the underlying conversation and event data are identical; meaning something’s re-triggering the event, or… something.
We’re listening on the WebSocket Notification API, obviously, and the JWT validation seems okay; but I’m starting to suspect there’s a race condition somewhere in the authentication flow. We’re pulling the JWT from the Genesys Cloud SDK for Node.js, version 2.1.0; and validating it locally before establishing the WebSocket connection. The token is refreshed every hour, just in case.
The Architect flow triggering these events is fairly simple; it’s a basic transfer blended campaign with a single disposition, and it’s pushing the conversation.updated event when the call ends. It’s not using any complex data actions or custom properties; or at least, none that should be causing this.
The Lambda handler is doing almost nothing; just parsing the event and logging to CloudWatch. For what it’s worth, we’ve checked the CloudWatch logs for the EventBridge bus itself, and aren’t seeing duplicate events there; which suggests the issue is somewhere between the EventBridge bus and our consumer. Here’s a snippet of how we’re establishing the connection:
const WebSocket = require('ws');
const jwt = require('jsonwebtoken');
// Assume 'token' is a valid JWT from the GC SDK
const ws = new WebSocket('wss://events.gc.genesys.cloud/events/v2/connections');
ws.on('open', () => {
console.log('WebSocket connection established');
ws.send(JSON.stringify({
type: 'authenticate',
jwt: token
}));
});
ws.on('message', event => {
// Parse and process the event
console.log('Received event:', event);
});
The biggest head-scratcher is why the duplicate events all seem to have the same timestamp; down to the millisecond. It’s like the notification is being sent twice simultaneously. I’m beginning to suspect the WebSocket connection is somehow getting reset and re-established without our handler knowing, leading to re-authentication; but I’m not seeing any disconnect events. Anyone else seen this madness?
ran into something kinda similar a while back lol. it’s almost always the event bridge filters tbh.
Quick Check - Event Filters
Double-check your EventBridge rule filters. Are you sure you aren’t accidentally matching events twice? I sometimes get the conversation.updated and conversation.metadata events mixed up. They look kinda same in the logs.
The JWT stuff… hmm. It’s usually a permissions issue. Make sure the role EventBridge is assuming has events.Read permissions for the conversation.updated event type. It’s super easy to miss, especially if you’ve been fiddling with roles.
FWIW, I always test with a super simple filter first (event.type == "conversation.updated") to rule out filter issues. YMMV. And yeah, I can’t find my full logs right now, sorry!
that fix worked; the scope on the EventBridge rule was too broad-it was picking up events from a dev org we didn’t realize was still publishing; narrowing it to our production account solved the duplicate issue; thankfully. it’s always something; isn’t it?
That’s right about the filtering - the EventBridge rules can be… tricky. We’ve seen this before. Heads up though, if you’re using the conversation.updated event, the payload contains multiple nested objects. The metadata field, for example, can trigger false positives if the filter isn’t precise.
Also, check the JWT validation process - it’s not just permissions. The signature algorithm must match what Genesys Cloud expects. RFC 7519 defines the process, but the implementation details matter. If the alg header is incorrect, you’ll get intermittent failures.
If it helps, can you show a sample of the JWT you’re presenting to EventBridge? It’s possible the claim structure is off. We had a case where the iss (issuer) claim was missing a leading character and the validation failed silently.
I’m still not clear on how you’re handling the initial handshake with the EventBridge endpoint. Are you using the Genesys Cloud SDK to generate the JWT, or rolling your own?
That’s right about the filters-we’ve seen similar issues with the API v2 endpoints. Sometimes the parser gets confused when the JSON payload has extra fields-try adding a schema validation step on the EventBridge side to drop events with unexpected data. We had to rebuild the consumer app after a change to the conversation.updated event structure last year.