Polymorphic deserialization of activity input fails (Isolated worker with Newtonsoft)

[stevenveerbeek]

We are migrating our durable functions from in-process to the isolated worker model. Some of our activities have input parameters that are typed as an interface or abstract class and we need to be able to determine the concrete type in our activities. In the in-process context, we used to customize the serializer settings by implementing our own IMessageSerializerSettingsFactory and setting TypeNameHandling to TypeNameHandling.All. This ensured that type metadata is included in the JSON so that the activity input could be deserialized correctly.

Regardless of whether this is considered good practice or not, it worked for us and we would like to continue this approach in the isolated model. We also opted for Newtonsoft again, which we configure in our DI container via WorkerOptions.Serializer (of course using TypeNameHandling.All again). However, when debugging our functions locally in the isolated model, the deserialization of these polymorphic activity inputs fails. For activity inputs typed as abstract classes, the JSON is deserialized into an instance of that abstract class. All information about the concrete type sent from the orchestration seems to have got lost. For interface-typed inputs, we get a JsonSerializationException saying "Could not create an instance of type <Type>. Type is an interface or abstract class and cannot be instantiated."

After some debugging we found something curious. It turns out that the serializer can handle polymorphism in activity inputs just fine, as long as the immediate input type is a concrete type, and any abstract classes or interfaces only occur in properties of the input type. An example:

We have an activity that has the following signature:

public async Task VehicleActivity([ActivityTrigger] IVehicle vehicle, CancellationToken cancellationToken)
{
    ...
}

From an orchestration we call this activity and pass an instance of a class Car : IVehicle. With Newtonsoft set as the serializer and TypeNameHandling set to TypeNameHandling.All, we expect the JSON of the the serialized Car instance to contain the $type metadata, enabling the worker to deserialize this into the IVehicle that the activity needs. Instead we get the JsonSerializationException mentioned before.

Now we modify the signature of the activity as follows (and modify the calling orchestration code accordingly):

public async Task VehicleActivity([ActivityTrigger] (IVehicle Vehicle, string Dummy) input, CancellationToken cancellationToken)
{
    ...
}

With the interface wrapped in a tuple, suddenly everything works as expected. We get no more exceptions and input.Vehicle has type Car.

This is on Microsoft.Azure.Functions.Worker.Extensions.DurableTask v1.7.0.

Our situation looks very much like the one described here: #2801 (comment)

[mmajcica]

We got in the same issue and that is stopping us for now to move over to isolated worker model. I would also like to add that it seems that the same classes if handled in orchestrations, e.g.

`
[Function(nameof(TestOrchestrator))]
public async Task TestOrchestrator([OrchestrationTrigger] TaskOrchestrationContext orchestration)
{
Acronym input = orchestration.GetInput();

await Task.Delay(1000);

}
`

it works as expected and there are no issues.
So it is only the activities that are influenced by this behavior.

[Ilia-Kosenkov]

Speaking from experience, avoid using value tuples, their serialization might be unreliable.
The simplest solution is to invent a Container with a single T Value, and use it as input. It will deserialize just fine. You can define implicit cast operators to masquerade this container as underlying type.

The same logic applies to return types, internal serializer uses runtime type, not declared return type, for serialization, which ignores all polymorphic configuration from STJ. Return a container with value and you are good to go.

[mmajcica]

Speaking from experience, avoid using value tuples, their serialization might be unreliable. The simplest solution is to invent a Container with a single T Value, and use it as input. It will deserialize just fine. You can define implicit cast operators to masquerade this container as underlying type.

The same logic applies to return types, internal serializer uses runtime type, not declared return type, for serialization, which ignores all polymorphic configuration from STJ. Return a container with value and you are good to go.

This is kind of a workaround, it would require a lot of refactoring for our apps. It would be nice if this would just work as it was for InProc. Or at least have something like IDurableActivityContext where the payload would be exposed as for orchestrations.

[Ilia-Kosenkov]

@mmajcica, well, you are not the first to hit this, and unfortunately the issue is quite deep in the framework (well, in-between two frameworks if I understood correctly). I filed an issue concerning return types a long time ago #3013.

[mmajcica]

@mmajcica, well, you are not the first to hit this, and unfortunately the issue is quite deep in the framework (well, in-between two frameworks if I understood correctly). I filed an issue concerning return types a long time ago #3013.

Indeed we checked the sources and it is not an easy fix or a quick change. Unfortunately. But in-proc next year will be done, and we will need to move. We where hoping and expecting that the move to isolated will be smoother.

[Ilia-Kosenkov]

We partially solved this by rolling out our own source generator that makes all orchestrations/activities strongly typed at all call sites. That way we can change the signature to accept Container<T>, but everywhere else it will appear as if we use the underlying T through implicit cast operators. Not ideal but it is something.