Renaming activity/ orchestrator input class

[adeliab]

I'm looking into refactoring our durable functions. Would the following changes break the functionality of durable functions:

• Renaming class of the input of an orchestrator/ activity
• Moving the class of input of an orchestrator/ activity to another function

I see the orchestrator instance & history Input only contain the serialized properties of the class. So I assume changing the class' name or namespace won't break the functionality. But then I saw a sub-orchestrator instance record and the input contains $type property which refers to the namespace of the input class. So it seems that it will be a breaking change.. can you confirm?

[cgillum]

Renaming the class of an input will be a breaking change if the serialized payload contains $type information. Whether it does depends on the settings of the serializer. I think that $type information is included only when the type is an instance of an interface or abstract class, but I'm not 100% positive. In addition to the Instance and History table entries, it would be good to see if you can also check the contents of the corresponding queue message (though this may be challenging since queue messages usually get consumed immediately after being sent).

One trick I've seen used is creating custom Newtonsoft.Json deserialization logic that takes care of migrating types at runtime. This might be an option worth considering, if possible.

[adeliab]

thanks chris. the classes that has $type in the Input field are not inheritances from abstract/ implementations of interface though. so i'm wondering why it's serialized with type. and indeed i tried to check the queue table but there's no message there.

there's quite a lot that I want to refactor from our durable function - but i feel that DF is very limiting in supporting changes. initially i thought only orchestrator/ activity names & payload property names that cannot be changed. but so far it seems like i can't move the storage account, i can't change the payload class name, can't move it to another folder either. it's quite frustrating

it feels like the only way to do this is to write a completely new function app but then there's the case of handling the existing runs.

[cgillum]

I see. Unfortunately, the $type stuff can be a little problematic when dealing with Newtonsoft.Json. I'm not an expert on it, but it can be customized and we have some documentation that talks about this here.

it feels like the only way to do this is to write a completely new function app but then there's the case of handling the existing runs.

Yes, unfortunately this is largely the reality when dealing with stateful apps. For what it's worth, the path we recommend is to deploy new apps with new code and run the two versions side-by-side, allowing old instances to drain and starting new instances with the new code. It allows you to freely make changes without needing to worry about compatibility between old and new data contracts. More documentation on this approach can be found in our Versioning documentation.