Polymorphic subtype deduction based on 'presence' of fields does not appear to take 'absence' of fields into account

Describe the bug Our use case involves the following: We are calling a web service that returns a JSON response that is a composite object. The object has a member field which is itself an object whos field members change depending on the service called, therefore we implemented this object as an interface with a number of different implementations corresponding to each different service, so it is a “polymorphic” member of the response object. Therefore, we placed the @JsonTypeInfo(use = DEDUCTION) annotation a top this interface definition.

In one particular service call, this response object returns with an empty object for this polymorphic member. When this case occurs, an error similar to the following is encountered(say we have only two implementations defined in the @JsonSubTypes annotation) :

com.fasterxml.jackson.databind.exc.InvalidTypeIdException: Cannot deduce unique subtype of `com.engageft.jackson.deserialization.issue.objects.AnInterface` (2 candidates match)
 at [Source: (String)"{
   "compositeClassIntMember":11235,
   "compositeClassStringMember":"compositeClassString",
   "polyMorphicMember":{
      
   }
}"; line: 6, column: 4] (through reference chain: com.engageft.jackson.deserialization.issue.objects.CompositeClass["polyMorphicMember"])
	at com.fasterxml.jackson.databind.jsontype.impl.AsDeductionTypeDeserializer.deserializeTypedFromObject(AsDeductionTypeDeserializer.java:131)

We then thought we’d try creating an implementation of this polymorphic member without any fields specifically for this case of an empty response object in the hopes that this mechanism would find this “empty implementation” and use it, but this did not work.

After examining the code found here, it appears that the case, or situation of if/when a particular implementation contains no data members is not being accounted for.

Other than this, we find this functionality absolutely fantastic and immensely helpful! Thank you for adding it! We hope that you might find a way to account for and solve this issue. I realize this is probably an outlier of a use case, and so is probably one that is very easily overlooked.

If you think you may benefit from any further assistance from me on this matter please do not hesitate to let me know 😃 .

Version information Which Jackson version(s) was this for? jackson-databind-2.12.0

To Reproduce I’ve created a small project which demonstrates this issue and it’s located here.

Expected behavior The tests in the test project should outline the whole thing, but if they don’t please let me know.

Additional context Can’t think of any at the moment, but if I do, I’ll amend this.

[lderienzo]

I added @JsonTypeInfo(... , defaultImpl = DefaultType.class) to the sample project but couldn’t get it to work as you suggested trying. I’ve pushed those changes to my sample project repo for you to look at.

I’m now actually wondering if there is a problem with defaultImpl when used with DEDUCTION. I found what might be a similar issue here.

[cowtowncoder]

True, implementation only considers properties found. It might be possible to figure out a fallback case, if (but only if) such could be uniquely determined. What could help here would be a set of example definitions along with JSON to outline expected case.

Another possibility is that existing @JsonTypeInfo(... , defaultImpl = DefaultType.class) could maybe be used (I would think that’d be fallback anyway).