jackson-databind: Deserialization of `@JsonTypeInfo` annotated type fails with missing type id even for explicit concrete subtypes

Here’s an example. We have a tool that generates Java / Kotlin classes from GraphQL schemas, so given an example trivial schema:

interface Animal {
  name: String
}

type Dog implements Animal {
  name: String
  barkVolume: Int
}
        
type Cat implements Animal {
  name: String
  lives: Int
}

type Query {
  animals: [Animal]
  dogs: [Dog]
  cats: [Cat]
}
       

We might generate the following for the Animal interface so that query for animals works correctly:

@JsonTypeInfo(
    use = JsonTypeInfo.Id.NAME,
    include = JsonTypeInfo.As.PROPERTY,
    property = "__typename"
)
@JsonSubTypes({
    @JsonSubTypes.Type(value = Dog.class, name = "Dog"),
    @JsonSubTypes.Type(value = Cat.class, name = "Cat")
})
public interface Animal {
  String getName();
}

Now when queries are also built using our codegen tool, we can always arrange for the __typename meta field to be returned, but some users may opt to only use the generated types and build their own queries by hand. To us the generated class even when querying for a specific type like Dog, they need to remember to also always ask for __typename, which seems a little strange to have to do if they are indicating at time of deserialization they know the concrete type based on the query they’re performing.

I can also think of non-GraphQL scenarios, where the client is using generated code and doing similar queries for REST endpoints like /animals, /dogs, and the server component is perhaps not using the same classes at all or is written in a different language. Yes, the /dogs endpoint could return JSON with type ids, but it seems redundant to have to do that when the client is specifically asking for a “concrete type” in this case.

I would also find this feature very useful.

I want to share a workaround which seems to work fine in my case: to annotate the subclasses with the same @JsonTypeInfo, but including a defaultImpl. For instance:

// Top-level interface

@JsonTypeInfo(
    use = JsonTypeInfo.Id.NAME,
    include = JsonTypeInfo.As.PROPERTY,
    property = "__typename"
)
@JsonSubTypes({
    @JsonSubTypes.Type(value = Dog.class, name = "Dog"),
    @JsonSubTypes.Type(value = Cat.class, name = "Cat")
})
public interface Animal {
  String getName();
}

// Subclasses

@JsonTypeInfo(
    use = JsonTypeInfo.Id.NAME,
    include = JsonTypeInfo.As.PROPERTY,
    property = "__typename",
    defaultImpl = Dog.class
)
@JsonSubTypes({
    @JsonSubTypes.Type(value = Dog.class, name = "Dog")
})
public class Dog implements Animal {
    // ...
}

@JsonTypeInfo(
    use = JsonTypeInfo.Id.NAME,
    include = JsonTypeInfo.As.PROPERTY,
    property = "__typename",
    defaultImpl = Cat.class
)
@JsonSubTypes({
    @JsonSubTypes.Type(value = Cat.class, name = "Cat")
})
public class Cat implements Animal {
   // ...
}

It is not exactly pretty, but it seems to be working as expected.

NOTE: as per #3853 this is OPT-IN for 2.15, so to allow deserialization you HAVE TO enable

MapperFeature.REQUIRE_TYPE_ID_FOR_SUBTYPES

so that the behavior is changed.

Ok, yay – this is now fixed for 2.15, and will be in the first 2.15.0 release candidate! Big Thank You to @JooHyukKim for the fix!

One future challenge: I was not able to merge the fix cleanly in 3.0 (master) – handling of polymorphic type resolution was refactored significantly and I could not see simple 1-to-1 translation. For now, then, tests wrt this issue are under failing in master. I will create a new follow-up issue for that.

Could not find clear example, but #2063 is similar.

I would be open to a PR that would accept missing type id in case of concrete subtype being requested, and have been planning on working on making this possible (but it did not make it in 2.12).

@kupci Annotation processing would not be optimized: they are checked when constructing (de)serializers, once, and never during runtime.

@JooHyukKim Unfortunately I don’t think that approach is correct; determination cannot rely on only abstract types using TypeDeserializers – intermediate concrete (or even base) types are perfectly legal for polymorphic handling.

• #3803

I started working on this issue on PR #3803 But it turns out there is quite a number of tests proving otherwise, testing that even deserialization of value as explicit concrete subtype should fail.

So to prevent myself from modifying loads of tests just to abort 😅, may I ask you to check if the change at PR #3803 is viable, @cowtowncoder ? 🙏🏼

Hi all, any news on this issue? Is marked as most-wanted for version 2.14 but is still open. Thanks