Trouble getting regular Dotnet Client working about fable.signalr HOT 10 CLOSED

Hey @kaeedo,

In order to receive sent messages you need to use the hub.OnMessage method like this:

let hub =
    SignalR.Connect<SignalRHub.Action, _, _, SignalRHub.Response, _>(fun hub ->
        hub
            .WithUrl(sprintf "http://127.0.0.1:5000%s" Endpoints.Root)
            .ConfigureLogging(fun l -> l.SetMinimumLevel(LogLevel.Debug))
            .OnMessage(printfn "%A"))

As for MsgPack, are you making sure that both the client and server both have the setting enabled?

from fable.signalr.

But according to the docs (https://shmew.github.io/Fable.SignalR/#/dotnet-client) You cannot define OnMessage at the declaration site of the hub, but rather at the points where you want to listen for a message. This is also the case when I try to add the OnMessage in my code. My editor (Rider in this case) yells at me, and dotnet build fails with The type 'HubConnectionBuilder<>' does not define the field, constructor or member 'OnMessage'.

And I double checked that I have MsgPack enabled on both sides. Still the same problem.

from fable.signalr.

Sorry I was still sleepy when I replied to this, yes you would do hub.OnMessage(...) from the created hub. I don't see this in your repro, am I not seeing a current version?

Is MsgPack not working for you with both libraries or only the vanilla version? If so, I'll take a look at the repro and see what the issue is.

This might help, you can see the full test models I run against both JSON and MsgPack protocols here.

from fable.signalr.

Thanks for the help. The key missing piece in my client code was actually a do! Async.Sleep(2000). I thought that doing do! hub.Send <| SignalRHub.Action.OnConnect 1 would wait for the request to be completely sent before the program exits, but I guess not. I have now also added an OnMessage handler which works correctly.

However, I'm still facing MspPack issues :(
I remember one of the other issues mentioned a version mismatch. I'll continue to play with it.

Thanks

from fable.signalr.

Sorry to reopen this, but I just can't get the MsgPack version to work. I've updated my minimal reproduction demo (Link again).

If the client hub is configured with UseMessagePack() on line 25, and the server (now Saturn) also is configured with use_messagepack on line 31 in Server, the client just hangs when it tries to send the first invoke, and the server seems to never receive the request.

Everything works just as expected when I comment out the UseMessagePack in the client and use_messagepack in the server.

I can confirm that running the tests in your repository works as well, so i'm just really confused at this point.

Thanks again

from fable.signalr.

No worries, I'll check out your reproduction and see if I can figure out what's going on.

from fable.signalr.

The problem is this
https://github.com/kaeedo/FableSignalRDotnetMinimal/blob/9ab20274fa2a78044b1e27c8732ead6bcba5643c/FableDotnet.Client/Program.fs#L19-L21

Even though you are not using the stream API, serializers are being created for the message types, which are inferred as obj here. Since obj serializer is not a thing, you'll need to replace it with a dummy type.

let hub: HubConnection<SignalRHub.Action, unit, unit, SignalRHub.Response, unit> =

Now the client runs and exists, though the logging is a bit weird.

from fable.signalr.

I'd suggest checking if any of the user provided generic types are obj and if so, swap them for unit so that the whole thing does not blow up, and maybe print a warning (then it might be a good idea to have a connect overload without streaming support).

As far as Fable.Remoting.MsgPack is concerned, it might be a good idea to identify obj early and throw a more reasonable error, but you should still expect an exception for unsupported types.

from fable.signalr.

Thank you so much. swapping out the _ for unit did the trick.

from fable.signalr.

Awesome thanks for the help @kerams! I'll see what I can come up with to prevent this from occurring on my side of things (or at the very least a note about this in the docs).

@kaeedo I think this has everything working as expected now, so I'm going to close this issue, but feel free to re-open if I'm mistaken.

from fable.signalr.