ConnectionManager.GetHubContext<T, TClient> does not broadcast to clients while ConnectionManager.GetHubContext<T> works fine

[ghost]

I have an asp.net web application that hosts a webapi controller and a signal R hub.
The app has a list page that details a list of a users last known locations.

The hub is implemented as follows..

public class LocationHub : Hub<LocationHubClient>
{
    public void BroadcastLocationUpdated(string locationName)
    {
        Clients.All.locationUpdatedCallback(locationName);
    }
}
// define an interface for the client side callbacks
public interface LocationHubClient
{
    void locationUpdatedCallback(string locationName);
}

The webapi has the following api function that is called from a mobile client and stores the users position in a DB and then broadcasts the location name to all connected clients by calling GlobalHost.ConnectionManager as follows..

[HttpPost]
public IHttpActionResult UpdateActivity([FromBody]UserLocationData location)
{
    // store in DB...
    // omitted for brevity

    // update clients...
    var hubContext = GlobalHost.ConnectionManager.GetHubContext<LocationHub , LocationHubClient>();
    hubContext.Clients.All.locationUpdatedCallback(location.name);
}

I'm passing two generic parameters to the GetHubContext method in order to strongly type my hubContext with the LocationHubClient type.
This code executes without error but does not broadcast the event to the clients. On inspecting the hubContext object in the debugger it looks like there are no clients connected.

I can get the code to work as expected by removing the second TClient generic parameter from the call as follows.

i.e. var hubContext = GlobalHost.ConnectionManager.GetHubContext<LocationHub>();

In this case where I don't specify TClient all of the connected javascript clients receive the event as normal using the following client side code.

var hub = $.connection.locationHub;
hub.client.locationUpdatedCallback = function (locationName) {
    console.log('Updated position',locationName);
    getUpdatedListFRomServerAndDisplay();
};

Is it possible that when specifying the both the T and TClient types the method is resolving the wrong hub context within the webapi method?

For reference my package versions are as follows..

  <package id="Microsoft.AspNet.SignalR" version="2.2.0" targetFramework="net45" />
  <package id="Microsoft.AspNet.SignalR.Core" version="2.2.0" targetFramework="net45" />
  <package id="Microsoft.AspNet.SignalR.JS" version="2.2.0" targetFramework="net45" />
  <package id="Microsoft.AspNet.SignalR.SystemWeb" version="2.2.0" targetFramework="net45" />
  <package id="Microsoft.AspNet.WebApi" version="5.2.3" targetFramework="net45" />

[IanYates]

I had a similar sort of issue in a muck around app I was writing and (someone else) found that I was telling SignalR about our dependency resolver twice - once by setting GlobalHost.DependencyResolver and once by passing it as an option to our MapSignalR call. Most things still worked but broadcasting was subtly broken similar to how you describe. In particular, getting a reference to a HubContext from outside of a SignalR call (such as what you're doing with WebAPI) seemed to give me an object that sent messages to a black hole.

[aspnet-hello]

This issue has been closed as part of issue clean-up as described in https://blogs.msdn.microsoft.com/webdev/2018/09/17/the-future-of-asp-net-signalr/. If you're still encountering this problem, please feel free to re-open and comment to let us know! We're still interested in hearing from you, the backlog just got a little big and we had to do a bulk clean up to get back on top of things. Thanks for your continued feedback!

[raymer]

@IanYates thank you sir. I went down the rabbit hole for hours before I saw your comment. Removing that from MapSignalR() fixed the issue for me.