search

Shmew / Fable.SignalR

A functional type-safe wrapper for SignalR and Fable.
https://shmew.github.io/Fable.SignalR/
MIT License
91 stars 17 forks source link

AddSignalR and UseSignalR overloads must match #31

Open kentcb opened 3 years ago

kentcb commented 3 years ago

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 commented 3 years ago

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.