Invalid negotiation response received about signalr

[ryancole]

FunctionApp4.zip

Here is a sample project of my client code that fails. It's a blank Azure Function HTTP Trigger function project, into which I pasted a few lines of code that tries to connect to my local hub server.

My hub server seems to work when being connected to from the browser. I have some javascript that is using the @aspnet/signalr package and it connects to my hub just fine.

[BrennanConroy]

I'm pretty sure Azure Functions are short lived "functions", so you can't have a traditional C# SignalR client running in them since they last for a single Http request basically.

Have you checked out the docs we have for the SignalR Service and Functions? https://docs.microsoft.com/en-us/azure/azure-functions/functions-bindings-signalr-service

[ryancole]

@BrennanConroy thank you for the quick reply!

I have checked those bindings out and they look super handy, but unfortunately we're currently targeting azure functions v1 because we need the .net framework support. I believe those bindings only work within a .net standard / core project, or possibly only on azure functions v2. I tried installing the package and got a whole host of compatibility errors. (Trust me, I put some serious thought into re-writing the whole thing to target Functions v2 and use .NET Core, but that involves finding replacements for some Windows-only third party libraries we use / pay for)

Alternatively, I tried directly accessing Azure SignalR Service, from my Functions code, via the REST API. I basically copy + pasted code from the serverless sample code on github that generates the JWT and puts together the HTTP request. This request seems to "go through", as I receive the "Accepted" HTTP response, but the message is never broadcast back out to other connected clients, it seems. I was having a difficult time debugging the REST API approach, so I attempted to revert back to the Microsoft.AspNetCore.SignalR.Client package approach.

You're right that the functions are short lived. Is that not acceptable for SignalR? These functions don't need to receive anything, I'm just trying to broadcast-only some messages intended to be read by other connected signalr clients.

[bradygaster]

What @BrennanConroy says is true, that the Function is short-lived and really, the only way to use SignalR with Functions is the bindings. This short-livedness isn't really an applicable SignalR scenario; you could use the client to connect to a hub and send a message, but you'd be connecting/disconnecting quickly (which could lead to other issues). The idea of SignalR is always connected.

You are correct that these are for .NET Core only, I'm 99% sure. Adding @anthonychu to validate these are only for Core but I'm pretty sure they are.

Here's an idea - you could create a second function that responds to incoming HTTP requests, then effectively turns around and pumps those back into the service. Then, you could use the binding to pump the messages into the service, and your existing V1 function could simply make HTTP requests to your "realtime proxy function." That would also give you more ability to reuse the "realtime proxy" in other scenarios later if you need.

[ryancole]

Thanks, @bradygaster.

I went ahead and introduced a second Functions application that target .NET Core and uses Functions V2. In that project I have a Service Bus-triggered Function that uses the SignalR output binding to dispatch messages to Azure SignalR service. That aspect of everything seems to be working now, as I can use Fiddler to log the HTTP requests and can see that the binding is indeed making the POST request to Azure and is getting an Accepted response.

I'm on to a whole new bit of confusion now though, as my browser-based @aspnet/signalr clients are not receiving the messages that I'm invoking from the Azure Functions application via the SignalR binding. I go into detail about my setup and that issue in #3349 though.