You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
The text was updated successfully, but these errors were encountered:
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.
Description
One must be sure to invoke the same
AddSignalR
andUseSignalR
overloads, otherwise confusing dependency resolution errors occur. For example, if one invokes:The following runtime error occurs when attempting to connect to the hub:
Steps to reproduce
AddSignalR
andUseSignalR
overloads, which causes a mismatch between types registered and types requested during resolutionExpected 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.The text was updated successfully, but these errors were encountered: