Add client handshake tracing for Tyrus standalone WebSocket client

Start with EndpointInstrumentation.CaptureHandshakeSpanAdvice and the upstream test named "if handshake is not captured traces are not generated"; trace how the Tyrus standalone client uses its Grizzly transport before Endpoint.onOpen(). Done means the client handshake span reaches onOpen() and the existing instrumentation produces websocket.send, websocket.receive, and websocket.close spans for the reproduction.

Library Name

Tyrus standalone WebSocket client with its Grizzly transport, optionally used through Spring StandardWebSocketClient.

Library Version(s)

• org.glassfish.tyrus:tyrus-standalone-client:2.2.0
• Jakarta WebSocket 2.x
• Also observed with Spring Framework 6.2.15 and Java 17.0.13

Describe the feature you would like

Please add end-to-end client handshake tracing for the Tyrus standalone Jakarta WebSocket client when it uses the Grizzly transport.

The existing Jakarta WebSocket instrumentation should then be able to associate the handshake span with the jakarta.websocket.Session and create websocket.send, websocket.receive, and websocket.close spans.

Is your feature request related to a problem?

Yes. The current generic Jakarta WebSocket instrumentation initializes its session state in EndpointInstrumentation.CaptureHandshakeSpanAdvice only when AgentTracer.get().activeSpan() is non-null during Endpoint.onOpen().

With a Tyrus standalone client, the HTTP upgrade and Endpoint.onOpen() callback execute through the Grizzly client transport without an active Datadog HTTP client span. Consequently, no HandlerContext.Sender is attached to the session. Later send and receive advice finds no handler context and creates no WebSocket message spans.

This was observed with:

• trace.websocket.messages.enabled=true
• JakartaWebsocketModule applied successfully
• jakarta.websocket.Endpoint and Spring StandardWebSocketHandlerAdapter transformed successfully
• no WebSocket-specific transformation errors
• ordinary HTTP, Redis, and other spans created and exported normally
• application WebSocket logs on Grizzly(...) threads showing no active trace or span IDs

A downstream agent build based on 1.63.4 was used for the initial observation. The same dependency on an already-active handshake span is still present on the current upstream main branch. The upstream test named if handshake is not captured traces are not generated also documents the resulting behavior.

Reproduction outline

Configure Tyrus as the Jakarta WebSocket client implementation, connect to an echo WebSocket server, register a message handler, and send a message:

WebSocketContainer container = ContainerProvider.getWebSocketContainer();
Session session =
    container.connectToServer(
        new Endpoint() {
          @Override
          public void onOpen(Session session, EndpointConfig config) {
            session.addMessageHandler(String.class, message -> received.countDown());
          }
        },
        URI.create("ws://localhost:8080/echo"));

session.getBasicRemote().sendText("hello");
received.await();
session.close();

Expected spans include a client handshake span followed by websocket.send, websocket.receive, and websocket.close. Currently none of the WebSocket spans are created because there is no active handshake span when Endpoint.onOpen() runs.

Alternatives considered

• Manually creating spans around each application-level send and receive handler.
• Propagating trace context in the WebSocket message payload.
• Creating a synthetic handshake span in generic Jakarta WebSocket instrumentation when no active span exists.

The preferred solution is dedicated Tyrus client handshake instrumentation that creates the handshake span and activates or propagates it into Endpoint.onOpen(), allowing the existing Jakarta WebSocket message instrumentation to work as designed.