You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
1.65.1 and current master (a1b6599a5f9f8d803cfac89fa1c3befe41b8c33f)
Java Version(s)
Oracle JDK 21.0.3
JVM Vendor
Oracle JDK
Bug Report
When DD_TRACE_WEBSOCKET_MESSAGES_SEPARATE_TRACES=false, received messages and peer-initiated close spans use the handshake span context, but locally initiated websocket.send and websocket.close spans still use the currently active context.
If there is no active span when Session.close() or RemoteEndpoint.send*() is called, those spans become roots of new traces. If another business span is active, they join that trace instead. In both cases they have a different trace ID from the WebSocket handshake.
This behavior comes from WebsocketDecorator.onFrameStart: the useDedicatedTraces setting is only checked when traceStarter is true. The traceStarter == false branch always calls startSpan(..., operationName) without the handshake context.
This was reproduced with Jakarta WebSocket and Tyrus 2.2.0, but the behavior is in the shared WebSocket decorator and is not Tyrus-specific.
The current result for one short-lived connection is:
The Java configuration documentation says that setting DD_TRACE_WEBSOCKET_MESSAGES_SEPARATE_TRACES=false causes all spans captured during the session to be in the same trace. Locally initiated send and close spans should therefore use the handshake trace as well:
When the setting remains at its default value of true, the existing behavior of outgoing operations following the current trace and linking to the handshake should remain unchanged.
Activity