-
Notifications
You must be signed in to change notification settings - Fork 325
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Relaxation of the discriminator validation #436
Comments
Do you think it makes sense to make it configurable and default to the current behaviour? For new APIs, we follow the rule strictly to enforce the validation based on the specification. However, for migrated APIs, we can make a configuration change to relax the validation for the project team to catch up. We just need to get it documented clearly so that migrated projects can make the configuration change in order to bypass the strict validation. What do you think? |
I don't think a configuration is the right level here as you might want to make the choice on a per schema basis. So the configuration would have to be schema aware, which you cannot really do |
As we have discussed in the forum, I understand the scenario now. I am reviewing the code and will merge and release it soon. Thanks. |
implemented and released. |
OpenAPI 3 requires that the field used for discrimination must be mandatory. While this of course is making sense for new APIs, APIs that get migrated step-by-step from Swagger and especially the clients can have a problem with this approach. Therefore the idea is to fall back in case of an absent discriminator value to standard
anyOf
validation.If the discrimination field is required in the schema, then validation will fail. If the schema is not requiring the discrimination field, behaviour is as in regular
anyOf
case with discriminators not being evaluated at all.The text was updated successfully, but these errors were encountered: