-
-
Notifications
You must be signed in to change notification settings - Fork 448
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
internalizeRefs
behaviour may not be consistent across multiple calls
#952
Comments
Changes between the two releases: v0.118.0...v0.120.0 |
The minimal-spec in percivalalb@04d5174 shows the issue:
|
I've started implementing a solution which improves the naming of internalized refs, it works ^TM . Needs some tidying up and iterating on but it fixes the issues seen upstream in oapi-codegen. |
I've not confirmed but I believe it's been an issue since the internalise ref functionally was added to kin-openapi given the comment: kin-openapi/openapi3/internalize_refs.go Lines 383 to 386 in f170f8c
|
Work that'll be part of https://github.com/getkin/kin-openapi/releases/tag/v0.126.0 should help with this issue. Feel free to reopen otherwise :) |
Hey folks,
I just wondered if you were aware of / had any insights into something we've had reported in oapi-codegen:
This leads to cases where we have two different resulting JSON representations of the specification (i.e. oapi-codegen/oapi-codegen#1572 (comment)) which in our case can cause noise for folks, but may be an actual bug we want to look at here.
This only appears to have been reported with oapi-codegen v2.1.0 onwards, in which we bumped from
v0.118.0
tov0.120.0
.The text was updated successfully, but these errors were encountered: