[Java] Don't throw exception with unknown polymorphic type

[bbdouglas]

Description

If a client receives an unknown discriminator label in a polymorphic type, it currently throws an exception deep in the feign stack. This makes it difficult to manage upgrades in a system of microservices, as it is difficult to co-ordinate every service upgrading simultaneously. To allow clients to gracefully degrade in the case unknown subtypes, it would be helpful for the stack not to throw an exception.

Swagger-codegen version

current (2.3.0)

Swagger declaration file content or url

Any polymorphic type, such as the Animal/Dog/Cat example in the sample spec.

Command line used for generation

N/A

Steps to reproduce

Imagine with the petstore example that the service started publishing a new animal called "Mouse" before the client upgraded its version of the spec.

Related issues

There are a number of issues generally related to polymorphism, such as #358, #1686 and #3904. But they touch on general support of the feature, while this is more on the topic of exceptional cases.

The one most closely related to this is #5436, which proposes an alternative solution to this problem. In all transparency, I work with @gstarnberger and we discovered together an issue with his approach. If you declare a default implementation as a subclass of the base class (such as UnknownAnimal as a subclass of Animal) then it makes it impossible to pass any responses with a subclass. That is, you can never return a Cat response, because Jackson would back off to an UnknownAnimal when it doesn't recognize the discriminator, and UnknownAnimal is not a subclass of Cat. Jackson recognizes this as an error at runtime and refuses (with yet another exception) to even attempt to parse the Cat.

Suggest a Fix

There is a feature of Jackson where it returns a null pointer instead of throwing an exception when it doesn't recognize a discriminator value. One achieves this by disabling the FAIL_ON_INVALID_SUBTYPE deserialization option. This is a nice approach because it gives the client the ability to degrade gracefully if it doesn't understand part of the response. It also exhibits parity with the feign client's handling of unknown enum values, which also returns null.

I have a small PR that makes this change.

[wing328]

Closed via #5597