fix(kotlin-spring): preserve 'default' response code in postProcessOperationsWithModels#23833
Open
mdemblani wants to merge 4 commits into
Open
fix(kotlin-spring): preserve 'default' response code in postProcessOperationsWithModels#23833mdemblani wants to merge 4 commits into
mdemblani wants to merge 4 commits into
Conversation
…erationsWithModels When an OpenAPI spec defines a 'default' response (no specific status code), the codegen internally represents it as code '0'. The existing logic unconditionally mapped '0' -> '200', causing generated @apiresponse annotations to incorrectly use responseCode = "200" instead of responseCode = "default". Fix: check resp.isDefault before mapping; only fall back to '200' for non-default zero-coded responses. Fixes OpenAPITools#17445
Contributor
There was a problem hiding this comment.
Pull request overview
This PR aims to fix the Kotlin Spring server generator so OpenAPI default responses are emitted as @ApiResponse(responseCode = "default") instead of incorrectly being rewritten to "200" during postProcessOperationsWithModels.
Changes:
- Update
KotlinSpringServerCodegen.postProcessOperationsWithModelsto map internal responsecode == "0"to"default"whenresp.isDefaultis true, otherwise keep the"200"fallback.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
…e code fix Updates 8 kotlin-spring sample files to reflect the fix for issue OpenAPITools#17445: createUser, createUsersWithArrayInput, createUsersWithListInput, and logoutUser operations in the petstore spec have `default` responses; their @apiresponse annotations now correctly use responseCode = "default" instead of "200". Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…pringHttpStatusLambda
SpringHttpStatusLambda threw IllegalArgumentException for the OpenAPI
'default' response code string, crashing generation for any kotlin-spring
config that uses useResponseEntity=false (which emits @ResponseStatus via
the lambda). Fix by mapping "default" → HttpStatus.OK, matching the
semantic intent of an unspecified fallback response.
Also guard the two other places that embed response.code as a literal:
- returnValue.mustache: HttpStatus.valueOf({{code}}) becomes
HttpStatus.valueOf(200) for default responses (keeps existing samples)
- api.mustache / apiInterface.mustache swagger1 ApiResponse(code=...):
code is an int, so default responses fall back to 200
Fixes: generateHttpInterface, generateHttpInterfaceReactiveWithCoroutines,
generateHttpInterfaceReactiveWithReactor, nonReactiveWithoutResponseEntity,
reactiveWithoutResponseEntity test failures.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…tating resp.code Per reviewer feedback, avoid mutating resp.code to the non-numeric string "default" in postProcessOperationsWithModels. That change required cascading fixes to SpringHttpStatusLambda, returnValue.mustache, and swagger1 templates because resp.code feeds into @ResponseStatus and HttpStatus.valueOf() calls that require a numeric status code. Cleaner approach: keep resp.code = "200" (the parent's behaviour) and emit responseCode = "default" in the swagger2 @apiresponse annotation by testing resp.isDefault directly in the Mustache template: ApiResponse(responseCode = "{{#isDefault}}default{{/isDefault}}{{^isDefault}}{{{code}}}{{/isDefault}}", ...) This is analogous to how the Java Spring generator handles default responses. With resp.code remaining numeric, SpringHttpStatusLambda (@ResponseStatus), returnValue.mustache (HttpStatus.valueOf), and swagger1 ApiResponse(code=...) all continue to work without modification. Also reverts the unnecessary SpringHttpStatusLambda "default" case, returnValue isDefault guard, swagger1 isDefault guards, and SpringHttpStatusLambdaTest "default" entry added in the previous commit. Adds a focused regression test (defaultResponseCodeRenderedAsDefault) that: - verifies ApiResponse(responseCode = "default") for operations with a default response (resolves reviewer comment 2) - verifies ApiResponse(responseCode = "200") for explicit-200 responses - verifies "0" never appears in generated output - runs with useResponseEntity=false to confirm no crash (covers issue OpenAPITools#17445) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
6 tasks
Member
|
please follow step 3 to update the samples: https://github.com/OpenAPITools/openapi-generator/actions/runs/26193287517/job/77142730074?pr=23833 |
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.
Description
Fixes #17445
When an OpenAPI spec defines a
defaultresponse (a catch-all with no specific HTTP status code), the generator internally represents it withcode = "0". The existing logic inKotlinSpringServerCodegen.postProcessOperationsWithModelsunconditionally mapped"0"→"200", causing every generated@ApiResponseannotation for default responses to incorrectly useresponseCode = "200"instead ofresponseCode = "default".Root cause
Fix
Check
resp.isDefaultbefore mapping — only fall back to"200"for non-default zero-coded responses:This mirrors the fix applied to
SpringCodegen(Java) in #14399.Generated code: before vs after
Before:
After:
Checklist
SpringCodegenpostProcessOperationsWithModelsSummary by cubic
Preserves the OpenAPI
defaultresponse in the Kotlin Spring generator without mutating response codes.@ApiResponsenow rendersresponseCode = "default"while numeric codes are kept elsewhere to avoid crashes withuseResponseEntity = false.resp.codenumeric inKotlinSpringServerCodegen.postProcessOperationsWithModels; emit"default"in swagger2 annotations via{{#isDefault}}inapi.mustacheandapiInterface.mustache.SpringHttpStatusLambdaor swagger1 templates; they continue using numeric codes.defaultResponseCodeRenderedAsDefaulttest to verify"default"is rendered, explicit200stays numeric, and"0"never appears.Written for commit aabbc52. Summary will update on new commits. Review in cubic