SignalR Java client failing on 'Headers not implemented yet.'

[mtinnes]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

The SignalR Java client is crashing when parsing Websocket messages containing a 'headers' section. Parsing of headers is not currently implemented in GsonHubProtocol.java, which is located here

The un-parseable payloads looks like this:

{
  "type" : 1,
  "target" : "Command",
  "headers" : {
    "traceId" : "0HNE2SNHO754E:00000001",
    "traceparent" : "00-e71ba9da7279d0683f29fc5054581a08-9518f7d2258253d7-01"
  },
  "arguments" : [ {
    "Name" : "getpackage",
    "Arg" : ""
  } ]
}

Seems if the payload contains 'headers', the Java client will crash.

This appears to be server-side and not related to any changes we made to our codebase.
My guess is that Microsoft has decided to add these headers automatically for tracing/debugging purposes.

We really need a way to disable these tracing headers as we have no way to update all our client apps in production.

Expected Behavior

SignalR websocket messages should not include 'headers', or have a method for disabling 'headers'. The SignalR Java client should not crash when receiving a websocket messages containing 'headers'.

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

.NET 9

Anything else?

No response

[BrennanConroy]

Looks like an oversight. We should be doing the bare minimum parsing and ignoring the values instead of throwing.

We ignored them in MessagePack but didn't for Json.

[mtinnes]

Thanks @BrennanConroy. Please let me know if you have any information regarding keeping these headers out of the websocket payload. It seems to be related to .NET distributed tracing - but we have not enabled any tracing on the server side. We're in a pickle with a large number of client apps crashing on this.

[shaqmate]

@BrennanConroy Just checking in to see if there’s any update or ETA on this fix. We're actively blocked by this in production

[mtrpst]

Yes we too. Lots and lots of our clients (1500+) that are crashing currently. We prefer a server side fix, since updating those clients one-by-one is a big and costly operation.

[stijnwop]

@BrennanConroy We're also encountering this issue in our production environment, and it's impacting stability. Could you share if there's any ETA or planned milestone for a fix? Any guidance or suggested workaround in the meantime would be greatly appreciated. Thanks!

[aderhgawen]

I also encountered this issue today. Is there any way to avoid it?

[mtinnes]

I also encountered this issue today. Is there any way to avoid it?

I've tried a number of things related to suppressing Tracing, but nothing has worked. I'm assuming the tracing headers are injected pretty low level in the SignalR hub itself. We are using the 'Default' SignalR mode where the hub has an associated hub server. I think the injection is happening in the hub rather than the server. We do not have any tracing or logging enabled on the hub.

[BrennanConroy]

I assume you all are using Azure SignalR Service? I don't think the base server sends any tracing data from the server to client right now.

We're going to update the Java client, and it looks like ASRS is planning on rolling back the changes.

[mtinnes]

Yes, SignalR Service in Default mode

[nikosreppaseb]

Hello we have the same issue as well. Is there an update regarding the resolution?

[vicancy]

declared outage and a global rollback is scheduled. ETA 3-6h.
Please leave your impacted regions or email me lianwei<at>microsoft.com your impacted resource names so I could prioritize your impacted resources.

[mtinnes]

East US