Autorest: Make discriminator lenient on missing values or missing values

[lmazuel]

There is two complex scenario with discriminator:

• When the JSON key to infer the type is completely missing
• When the JSON key to infer the type is there, but point to a value that is not defined in the Swagger.

Currently, C# generator accepts both scenario, and return the base class (i.e. the class mentioned in the Swagger). Other language fails (at least Python/Node, but I have no reason to think other languages accept this scenario, and this they do, just remove your label here :)).

Looking at the Swagger spec, the "correct" behavior is not enforced:

https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#discriminatorObject
If the discriminator value does not match an implicit or explicit mapping, no schema can be determined and validation SHOULD fail.
[…]
SHOULD: This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

We hit this problem with the Cognitive Services DataPlane, which _cannot_ be used with Autorest if the discriminator parsing is not lenient (was discussed a lot with @amarzavery, @johanste and me for the SDK side, and @stefanvalianu for the CS side).

Conclusion is, that in order to support CS Dataplane, all languages SDK _must_ implement the lenient behavior, as C# does.

Changes are already made in Python FYI:
https://github.com/Azure/msrest-for-python/pull/64

The idea is tested on C# samples, and Python samples:
https://github.com/Azure-Samples/bing-search-dotnet
https://github.com/Azure-Samples/bing-search-python

[fearthecowboy]

Totally agree.

[mcardosos]

Are there plans to add this scenario to the test server?

[amarzavery]

We have fixed this issue for nodejs. The fix was mostly involved in ms-rest (runtime). This is the PR in node sdk that fixes it. https://github.com/Azure/azure-sdk-for-node/pull/2332.

I think we should also have a test for this scenario in the test server. Response to a GET request should fallback to deserializing the immediate parent if a child is not found.