fix: correct sibling logic when reading type from schema annotation#5237
Closed
Mattias-Sehlstedt wants to merge 1 commit into
Conversation
Mattias-Sehlstedt
force-pushed
the
correct-sibling-logic-when-reading-type-from-schema-annotation
branch
from
July 15, 2026 18:58
c349630 to
57331d9
Compare
Mattias-Sehlstedt
force-pushed
the
correct-sibling-logic-when-reading-type-from-schema-annotation
branch
from
July 15, 2026 21:55
57331d9 to
46c0d67
Compare
Contributor
Author
|
Closed since this goes further than solving the initial issue and instead also starts to try to implement proper type overriding. That is better left as separate issue since it should be a |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull Request
Thank you for contributing to swagger-core!
Please fill out the following information to help us review your PR efficiently.
Description
Introduces an intermediate fix for the issue reported in #5235. It does not solve the sibling handling in its entirety, since it only adjusts the type if
typescontains a single value (this is aimed to give a fallback for the logic implemented for OAS 3.0. This sincetypeandtypesare now better isolated from each other, and the resolver expect the user to use the right field for the right OAS version).For OAS 3.1 it is currently not possible to entirely handle
typessince it is converted into a single type that is fed intoAnnotatedType. For a real scenario the entire type array should be utilized and passed along.This also comes with the behavior of coercing the string value for the
typeinto aPrimitiveType. This might in turn lead toformator similar being calculated forinteger, which might not always be what one expects when using@Schema(types = {"integer"}).Fixes: #5235
Type of Change
Checklist
Screenshots / Additional Context