FSharp API: fixed problem with JObject deserialization

[Horusiath]

This should fix #999 . The issue was that F# actor applied pattern matching on the generic type in case when message was not fully deserialized (it was an intermediate representation in form of json.net JObject). In result any try of pattern matching was failing.

This PR solves that problem by adding additional step - in case when we have a JObject instance passed it tries a build in ToObject(type) conversion and if it succeeds, pass the result to the actor's receive function.

[rogeralsing]

How will this play with F# Akka.Persistence?

The problem is in the serializer, and I'm guessing that we might end up findning these JObjects in a lot of unexpected places eventually (?)

The fix looks good otherwise

[Aaronontheweb]

How will this play with F# Akka.Persistence?

Isn't the JObject on the read-side only?

[Horusiath]

@rogeralsing @Aaronontheweb This should be also included in Akka.Persistence.FSharp.

[Aaronontheweb]

@Horusiath looks good to me, but a suggestion: could we add a spec to the F# specs somewhere that tests for this issue specifically? Or modify an existing DU serialization spec to address the issue that you pointed out earlier? Given the trouble we've had with this issue it seems like an area where it's worthwhile to do that :p

[rogeralsing]

It's worth noting that this is more of a workaround than a final fix, e.g. if a C# system would for some reason consume F# messages, the same error will show up again.

And if a DU is passed remote to a consistent hash router to be forwarded to a F# actor, the hashing will occur on the JObject as it has not yet been converted yet.
So this is somewhat fragile.

[Aaronontheweb]

And if a DU is passed remote to a consistent hash router to be forwarded to a F# actor, the hashing will occur on the JObject as it has not yet been converted yet.
So this is somewhat fragile.

Argh!

In that case... what would we need to do to completely solve the problem.

[Horusiath]

Sorry, but this one still doesn't solve the problem - I've found that JSON.NET fails on deserialization of integer values inside DUs (as they are wrapped in dedicated struct to maintain int type info).

[rogeralsing]

Hold your horses :)

You need to pass the NewtonSoftJsonSerializer._serializer to the ToObject method also, not only the type.
The _serializer field is not exposed publicly atm, but we can absolutely add a property for that, just like we have for NewtonSoftJsonSerializer.Settings

So this line:

toObjectMethod = jobjectType.GetMethod("ToObject", [|typeof<System.Type>|])
should be
toObjectMethod = jobjectType.GetMethod("ToObject", [|typeof<System.Type>,typeof<JsonSerializer>|]) where jsonserialzer is theNewtonsoft type, not ours.

and

Some (toObjectMethod.Invoke(o, [|t|]) :?> 'Message)
should be
Some (toObjectMethod.Invoke(o, [|t, ourNewtonSoftJsonSerializer.Serializer|]) :?> 'Message)

Where the ourNewtonSoftJsonSerializer is our newtonsoft json serialzer.

[Horusiath]

@rogeralsing still won't work, because even if message passing between F# actors will be correct, everything will fail on F#/C# actors interop or even in ask operators (for both F# and C#) used outside an actor. This must be solved from the default serializer side.

[Horusiath]

This time I've created a little bigger workaround that is reusable (applied in both Akka.FSharp and Akka.Persistence.FSharp) and works also on ask operator <?. Additional test to verify remote deployment message serialization/deserialization applied.

[rogeralsing]

Add some comments on the affected code, if we find a better way to solve this later.

[rogeralsing]

👍 looks solid

[Aaronontheweb]

Should we mark this field as internal here? Any reason to make it public?

[Horusiath]

To implement this workaround, field must be public (or reacher via reflection) and it must return object and not direct serializer (to maintain Akka.FSharp free from direct dependency on JSON.NET).

[Aaronontheweb]

Just so I understand this better - could you walk me through where we're using FsPickler and JSON.NET in the serialization flow for F#? I took a look through it and think I have an idea as to what's happening but I'm not 100% there (although my F# is getting better!)

[Horusiath]

@Aaronontheweb JSON.NET is default serialization mechanism in F# .NET. But for few custom type based on F# quotations we use FsPickler rigth now.

[CumpsD]

Did this make it in a release already?