Conversation
There was a problem hiding this comment.
Pull request overview
This PR fixes a bug (issue 1225) where oneOf validation with a discriminator mapping incorrectly succeeded when the discriminator-indicated schema failed validation but a different, non-discriminated schema happened to pass. The fix adds a new assertion in OneOfValidator to detect this mismatch and report a discriminator error.
Changes:
- Added a new condition in
OneOfValidator.validate()to fail validation when the discriminator-mapped schema has errors but exactly one other schema passes, treating this as a discriminator mismatch. - Updated the existing test
discriminatorOneOfOneMatchWrongDiscriminatorShouldFail(renamed from...ShouldSucceed) inOpenApi31Testto verify the fix using the petstore schema. - Added a new test
oneOfDiscriminatorEnabledWithDiscriminatorMismatchinDiscriminatorValidatorTestto verify the fix with an inline schema using explicit discriminator mappings.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
src/main/java/com/networknt/schema/keyword/OneOfValidator.java |
Core fix: adds discriminator mismatch detection when the mapped schema fails but another schema passes in oneOf |
src/test/java/com/networknt/schema/oas/OpenApi31Test.java |
Updates existing test to expect failure and verify discriminator error keyword |
src/test/java/com/networknt/schema/DiscriminatorValidatorTest.java |
Adds new test for discriminator value mismatch with explicit mapping |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
After the fix, it breaks an existing test case. I am not sure if this fix is correct or not. Please pay more attention before merging this PR. Thanks. |
|
The spec at https://spec.openapis.org/oas/v3.1.1.html#discriminator-object states:
So this change likely goes against the spec. Removing or adding the discriminator in a schema shouldn't change the validation outcome. |
|
Based on the comment from @justin-tay, we should drop this PR as the current behaviour is correct. |
No description provided.