Orleans IPersistentState POCO Namespace/Class Library Versioning problems

[zharchimage]

Hi everyone. First of all thanks for this amazing project that I'm in love since I heard about it some years ago. I'm building a server app, and the only problems I'm facing is when I'm refactoring Grain IPersitentState POCO objects like this:

 namespace BaseNamespace.OldNameSpace;
 [GenerateSerializer, Alias("MyRecord")]
 public sealed record MyRecord
 {
    [Id(0)]
    public string Name{ get; set; }
    [Id(1)]
    public int Age { get; set; }
 }

This POCO object is in thenamespace BaseNamespace.OldNameSpace and Class library/DLL MyProject.Common.Model.
I'm doing CRUD operations from a grain called MyRecordGrain and use SQL Server to persist the grains state. In order to rehydrate the grain when it is invoked I have the following in the constructor:

public sealed class MyRecordGrain([PersistentState(stateName: "MyRecordValue", MyRecordStorageKey")] IPersistentState<MyRecord> state) : IGrain, IMyRecordGrain

Whenever I write to the state it is persisted properly to the SQL Server database, and I can see the JSON from the PayloadBinary column after running the command select cast(PayloadBinary as varchar(MAX)), * from OrleansStorage

{
    "$id": "1",
    "$type": "BaseNamespace.OldNameSpace.MyRecord, MyProject.Common.Model",
    "Name": "Anthony",
    "Age ": 14,
},

I can see there that both the namespace and the class library name are strongly embedded in to the type property. While calling the MyRecordGrain the state is properly loaded and everything is ready to go.

However, I have been heavily refactoring the model classes and I have changed them from the old namespace to BaseNamespace.NewNameSpace and from different class libraries to MyProject.Common.Orleans.Model. It was my understanding, that because we specify the exact type on the constructor of the grain as [PersistentState(stateName: "MyRecordValue", MyRecordStorageKey")] IPersistentState<MyRecord> state the PayloadBinary field was going to be simply serialized to the specified generic type, MyRecord in this example, but because the namespace and the class library changed during the refactoring, I'm receiving this error when I call the grain and it tries to load the state:

 Error from storage provider AdoNetGrainStorage.personCache during ReadStateAsync for grain personCache/PersonCacheKey
 
Exc level 0: Newtonsoft.Json.JsonSerializationException: Error resolving type specified in JSON 'BaseNamespace.OldNameSpace.MyRecord,  MyProject.Common.Model], System.Collections.Concurrent'. Path '$type', line 1, position 263.
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.ResolveTypeName(JsonReader reader, Type& objectType, JsonContract& contract, JsonProperty member, JsonContainerContract containerContract, JsonProperty containerMember, String qualifiedTypeName)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.ReadMetadataProperties(JsonReader reader, Type& objectType, JsonContract& contract, JsonProperty member, JsonContainerContract containerContract, JsonProperty containerMember, Object existingValue, Object& newValue, String& id)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.CreateObject(JsonReader reader, Type objectType, JsonContract contract, JsonProperty member, JsonContainerContract containerContract, JsonProperty containerMember, Object existingValue)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.CreateValueInternal(JsonReader reader, Type objectType, JsonContract contract, JsonProperty member, JsonContainerContract containerContract, JsonProperty containerMember, Object existingValue)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.Deserialize(JsonReader reader, Type objectType, Boolean checkAdditionalContent)

Worth reiterating again, that if I do not change the namespace nor the class library everything works fine. And I already know that there is an Alias I can use to help the serializer isolate from future versioning problems, but it looks like it is adding the whole namespace always regardless of this Alias which is strongly bound to during the deserialization.

Is there any kind of good practice around this problem? What I have thouth is on adding the Orleans PersistentState classes to the same isolated Orleans library under a short fixed namespace namespace Orleas.Model and never refactor that in the future. Is this the proper way to do it? Is there any other way I can circunbent the serializer logic to escape the namespace restrictions?

Thanks in advance!

[ReubenBond]

Hi @zharchimage, Orleans.Serialization is not used by default for storage, so what you're setting is the result of Newtonsoft.Json (the default) being used and not coping with the name change. Newtonsoft.Json also has a mechanism for that called a [ContractResolver] (https://www.newtonsoft.com/json/help/html/ContractResolver.htm)

EDIT to clarify: the GenerateSerializer/Id/Alias attributes are used by Orleans.Serialization, which is used for RPC and optionally for storage. It can be used for storage serialization by adding it to DI using builder.Services.AddSingleton<IGrainStorageSerializer, OrleansGrainStorageSerializer>(), thus overriding the default. We picked Newtonsoft.Json as the default because JSON is a common format and people are familiar with Newtonsoft.Json, which is the most mature JSON serializer for .NET

[zharchimage]

Thanks for the quick answer, going to try that solution.

[zharchimage]

Hi, I did some research and had to change the Json configuration as you suggested. Apparently there is a flag in the JsonSerializerSettings that adds the full TypeName to the serialization as it was happening by default https://www.newtonsoft.com/json/help/html/serializetypenamehandling.htm

Followed the configuration suggested in https://github.com/dotnet/docs/issues/33943

siloBuilder.Configure<OrleansJsonSerializerOptions>(options =>
{
    options.JsonSerializerSettings.TypeNameHandling = TypeNameHandling.Auto;
})

And everything works fine. No assembly nor namespace added to de serialized JSON.

Thanks for the help again!