Server sent events not firing onclose/reconnect event on expiration of JWT

Describe the bug

To test that our reconnection logic on the expiration of the Azure SignalR JWT worked correctly, I set the AccessTokenLifetime to 1 minute.

services.AddSignalR()
                .AddNewtonsoftJsonProtocol()
                .AddAzureSignalR(o =>
                {
                    o.AccessTokenLifetime = TimeSpan.FromMinutes(1);
                });
        

Whilst using WebSockets, as expected, there was no disconnection after 1 minute and the connection remained open for the duration of testing. Whilst using LongPolling, as soon as a 401 error is received from a long poll response, the onclose event is fired allowing us to manage a reconnection.

However, whilst using SSE, the occasional ping or attempt to post a message back to the Azure SignalR server results in a 401 error that does not appear to initiate an onclose or reconnect event. As such, we have no way to know that the communication between the server has now broken, and cannot force it to renegotiate.

This makes SSE functionally unusable with Azure SignalR as our clients will permanently disconnect after the 1 hour JWT timeout.

To Reproduce

As above, using a short JWT expiry and the following javascript connection:

new signalR.HubConnectionBuilder()
            .withUrl(connectionUrl,
                {
                    transport: signalR.HttpTransportType.ServerSentEvents,
                })
            .withAutomaticReconnect() //optional, but neither reconnection nor onclose are occurring
            .build();

Exceptions (if any)

The console fills with the following errors, however no attempt to reconnect trigger an ‘onclose’ or ‘onreconnecting’ event occurs.

With LongPolling, we receive a single error, followed by a reconnection (onclose without the withAutomaticReconnect())

Further technical details

• Your Azure SignalR SDK version: Microsoft.Azure.SignalR@1.5.0
• Your SignalR Client SDK version: Javascript - microsoft-signalr@3.1.3

[BozeTadic]

Oh what version of the client library are you using?

The client library version is “^6.0.4” The change seems to be the renamed cachedPingMessage > _cachedPingMessage.

It works with the underscore. A simple oversight.

await connection.start()
await connection.sendMessage(_connection.cachedPingMessage);

Thank you for helping.

[vicancy]

does not mimic the ping message correctly and sends a regular type 1 message with cachedPingMessage string value as content.

Oh what version of the client library are you using? I just did a quick test and it did work with json protocol and 5.0 js client

await connection.start()
await connection.sendMessage(connection.cachedPingMessage);