Json Deserialization Errors When Changing WF Params Schema

[dflor003]

Describe the bug

Whenever we make any changes to the params object that a workflow takes, it has the potential to break workflows that are out in our prod system. Even superficial changes like changing the namespace or name of a class will break deserialization due to the specific serialization settings in NewtonSoft Json.Net.

To Reproduce Steps to reproduce the behavior:

1. Create a workflow and workflow params with one class name
2. Run the workflow a couple of times
3. Change the name of the params class
4. Try to load old workflow instances

Expected behavior

Expected: Workflow should system should be smart enough to load up old workflows just based off the expected schema to deserialize into. Actual: When trying to load old workflows, you get a bunch of deserialization exceptions.

Additional context

For context, this is when using the MySQL provider for WF Core. When using that provider, it serializes the Data field as well as other fields using a statically created instance of JsonSerializerSettings in WorkflowCore.Persistence.EntityFramework.ExtensionMethods. This instance specifies a TypeNameHandling on it which causes it to emit type information into the JSON blob that gets saved into the database.

A way to fix this may be to allow you to inject the JsonSerializerSettings used or even provide some kind of IJsonSerializer interface that consumers of the lib can implement.

[vladimir-kovalyuk]

@dflor003 have you tried creating another WF definition with incremented Version property? I've never tried myself, just keeping it in mind for cases when we would have to make changes in WF.

[phija]

I would also like to see that feature of using our own jsonSerializerSettings: We use UnitsNet library for data also sent via a web API and could use basically the same json serializer on the storage side to handle IQuantity.