dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.39k stars 4.75k forks source link

Json deserialization of polymorphic types does not expose the discriminator value #108885

Open blowdart opened 1 month ago

blowdart commented 1 month ago

When using polymorphic types with System.Text.Json and configuring FallBackToNearestAncestor and IgnoreUnrecognizedTypeParameters to true you cannot tell the Json type discriminator of unrecognized objects.

To give a real-world example, I talk to a preferences API which returns multiple types of preferences, so I have a base class/record Preference

[JsonPolymorphic(UnknownDerivedTypeHandling = 
  JsonUnknownDerivedTypeHandling.FallBackToNearestAncestor,
  IgnoreUnrecognizedTypeDiscriminators = true)]

[JsonDerivedType(typeof(......)]
public record Preference
{
    [JsonConstructor]
    public Preference() {}

    [JsonExtensionData]
    public Dictionary<string, JsonElement>? ExtensionData {get; set;}
}

The idea being that if the api needs a new type of preference I don't have a derived class for then deserialization will still succeed, falling back to create an instance of Preference, with the unknown properties exposed in the ExtensionData.

Then in parsing a collection of preferences I can use pattern matching to act on the derived types.

However, when deserialization falls back to using the preference class I get everything in the ExtensionData except for the type discriminator value. This makes it impossible to make a reasoned decision about what to do with the data.

If the preferences API added two new types which have the same shape, say

{
    "$type": "legume",
    "description": "a type of legume"
},
{
    "$type": "beans",
    "description" : "the best type of legume"
}

then after deserialization I would get is the description in the extension data with no way of telling the types apart. So, you need to expose the type property somewhere.

My suggestion would be if deserialization has fallen back because the type is unknown and there is an extension data property then also insert the type value into that, or, if the fallback class/record has a property of string where the JsonPropertyName value matches the TypeDiscriminatorPropertyName property on the JsonPolymorphic attribute, feed it into that as well.

If you go the property router then during serialization any JsonInclude property which has a JsonPropertyName which matches the TypeDiscriminatorPropertyName property on the JsonPolymorphicattribute could be ignored by default.

dotnet-policy-service[bot] commented 1 month ago

Tagging subscribers to this area: @dotnet/area-system-text-json, @gregsdennis See info in area-owners.md if you want to be subscribed.

eiriktsarpalis commented 1 month ago

The current behaviour is by design in that type discriminators are a type-level mapping, as such it cannot be mapped from properties or extension data of a particular instance into the wire or vice-versa. We might consider exposing an additional flag on JsonPolymorphicAttribute that enables deserialization-only binding of unrecognized discriminators either on properties or extension data dictionaries. The design would be making it explicit that such values would not be roundtripped back into the wire.