WebSocket reconnect drops trace context in OTel spans

I’m setting up a Node.js service to listen to Genesys Cloud conversation events via the Notification API WebSocket. The goal is to capture the traceparent header from the initial connection and propagate it into our OpenTelemetry spans for every event we receive.

The connection works fine initially. I get the connected event and can see the headers in the handshake response. The problem is when the WebSocket drops and reconnects automatically. The new connection doesn’t seem to carry over the original trace context, so my spans get split into two separate traces in Jaeger.

Here’s the connection code:

const ws = new WebSocket('wss://api.mypurecloud.com/v2/notification/events', {
 headers: {
 'Authorization': `Bearer ${token}`,
 'traceparent': currentSpanContext
 }
});

ws.on('open', () => {
 console.log('Connected');
 // Subscribe to conversation events
 const subscription = {
 type: 'conversation',
 events: ['conversation.updated']
 };
 ws.send(JSON.stringify(subscription));
});

When the close event fires, I restart the WebSocket. The new handshake gets a new traceparent from the server, but I’m not sure how to link it back to the original parent span.

Is there a way to force the server to reuse the existing trace ID on reconnect, or do I need to handle the span linking on the client side? I’ve tried setting the W3C Trace Context header on the new connection but it gets ignored.

Anyone else dealing with trace continuity across WebSocket reconnections?

The reconnection handler resets the context. You need to capture the traceparent from the initial handshake and inject it manually into the OpenTelemetry context before processing subsequent events.

const ctx = trace.setSpanContext(active, extractedContext);
withContext(ctx, () => processEvent(data));

Check the reconnect callback logic.