Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AddSignalR and UseSignalR overloads must match #31

Open
kentcb opened this issue Sep 1, 2021 · 1 comment
Open

AddSignalR and UseSignalR overloads must match #31

kentcb opened this issue Sep 1, 2021 · 1 comment

Comments

@kentcb
Copy link

kentcb commented Sep 1, 2021

Description

Reporting this because it took me a couple hours to figure out.

One must be sure to invoke the same AddSignalR and UseSignalR overloads, otherwise confusing dependency resolution errors occur. For example, if one invokes:

services.AddSignalR(signalRSettings, streamToClient)

// Oops, forgot to pass in streamToClient
app.UseSignalR(signalRSettings)

The following runtime error occurs when attempting to connect to the hub:

fail: Microsoft.AspNetCore.SignalR.HubConnectionHandler[1]
      Error when dispatching 'OnConnectedAsync' on hub.
System.InvalidOperationException: Unable to resolve service for type 'Fable.SignalR.BaseFableHubOptions`2[Microsoft.FSharp.Core.Unit,Microsoft.FSharp.Core.Unit]' while attempting to activate 'Fable.SignalR.BaseFableHub`2[Microsoft.FSharp.Core.Unit,Microsoft.FSharp.Core.Unit]'.
   at Microsoft.Extensions.DependencyInjection.ActivatorUtilities.GetService(IServiceProvider sp, Type type, Type requiredBy, Boolean isDefaultParameterRequired)
   at lambda_method(Closure , IServiceProvider , Object[] )
   at Microsoft.AspNetCore.SignalR.Internal.DefaultHubActivator`1.Create()
   at Microsoft.AspNetCore.SignalR.Internal.DefaultHubDispatcher`1.OnConnectedAsync(HubConnectionContext connection)
   at Microsoft.AspNetCore.SignalR.Internal.DefaultHubDispatcher`1.OnConnectedAsync(HubConnectionContext connection)
   at Microsoft.AspNetCore.SignalR.HubConnectionHandler`1.RunHubAsync(HubConnectionContext connection)

Steps to reproduce

  1. Per the above, you just need a mismatch between AddSignalR and UseSignalR overloads, which causes a mismatch between types registered and types requested during resolution

Expected behavior

At minimum, it would be nice to have a good runtime error message guide the dev here. But I'm also not sure why the split between send/invoke and streaming exists. If Settings had streaming-related properties in it too, there would be no need for multiple overloads and hence no chance of mismatching calls.

@Shmew
Copy link
Owner

Shmew commented Sep 4, 2021

Hi @kentcb,

There are a lot of hoops to jump through to force everything to be type safe with how hubs are constructed. Due to how SignalR works I have to return a specific type based on the features the user opts into. I'm able to ensure this type of thing can't happen with Saturn since I'm able to apply both AddSignalR and UseSignalR during the build method of the CE.

I'm not sure if it's possible for me to add a check to give a better experience when this does happen, I'll have to circle back and do some investigating.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants