[Java Client] HTTP errors during WebSocket handshake not surfaced as HttpRequestExceptions

[codylund]

Is there an existing issue for this?

• [X] I have searched the existing issues

Describe the bug

If an HTTP response for the opening SignalR negotiate call contains an unexpected response code, the SignalR Java client library will convert the error to an HttpRequestException for use by consumers of the library. However, if negotiation is skipped and a similar error occurs during the opening WebSocket handshake, the library does not return a useful exception. Instead, OkHttpWebSocketWrapper.SignalRWebSocketListener.onFailure() ignores the Response returned by OkHttp and wraps the provided Throwable in a RuntimeException.

This makes certain handleable errors, like 401, especially difficult to detect. I believe the only recourse today is to parse the error message string on the underlying Throwable returned by OkHttp.

Expected Behavior

When negotiation is skipped, SignalR should return HttpRequestExceptions for the opening HTTP handshake in the WebSocket protocol, so we can handle the error codes (like 401) appropriately.

Steps To Reproduce

1. Set up a basic SignalR Java client and SignalR service that supports authentication.
2. Configure the SignalR client to use WebSocket transport and skip negotiation.
3. Provide a bad token for the connection.

Expected: SignalR Java client receives an HttpRequestException with a 401 code. Actual: SignalR Java client receives a generic RuntimeException.

Exceptions (if any)

No response

.NET Version

No response

Anything else?

No response

[Rishan99]

Any update around this?

[abelmatos]

Can we also remove the error log? We shouldn't log it if an Exception is thrown. https://github.com/dotnet/aspnetcore/blob/21e8836755b8be5f7fc7bf35d9f5b87ae60b62a0/src/SignalR/clients/java/signalr/core/src/main/java/com/microsoft/signalr/OkHttpWebSocketWrapper.java#L135