-
Notifications
You must be signed in to change notification settings - Fork 75
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
[BUG] (type-safe-api) (regression) Path param on path level not recognize properly #841
Comments
Furthermore in a case of a schema using allOf the model fail to import components too in the model Try with: components:
Template:
allOf:
- $ref: '#/components/schemas/TemplateBase'
- $ref: '#/components/schemas/TemplateBody'
- title: Template
description: |
Represents a complete template in the system.
TemplateBase:
type: object
title: TemplateBase
description: |
Represents the base properties of a template.
additionalProperties: false
required:
- id
properties:
id:
$ref: '#/components/schemas/TemplateID'
TemplateBody:
type: object
title: TemplateBody
description: |
Represents the body of a template.
additionalProperties: false
properties:
parent_id:
$ref: '#/components/schemas/TemplateID'
boolean:
type: boolean
description: A boolean value.
TemplateID:
type: string
format: uuid
title: TemplateID
description: The unique identifier for a template.
maxLength: 36 And i got:
Again it's not the exact same error like the |
Hey Vale! Thanks for raising this! Since 0.23.50 we've replaced openapi-generator with our own code generator for most of the typescript projects. While it's much faster and doesn't have the dependency on Java, it seems I've missed some edge cases here! I'll investigate the three problems you've raised in this issue, don't worry about separating them :) For now, I'd recommend pinning at 0.23.49 so you're not blocked :) |
Parameter models were not being imported in the API client in the typescript runtime. References #841
…fault responses OpenAPI generator treated "default" responses as responses with code 0, however parseOpenapi treats default as 200. Adjust code generation to follow OpenAPI for backwards compatibility and to avoid duplicate 200 responses. Note that this should be revisited such that code generation allows for any response code other than those defined to be returned for the default response, rather than 0. References #841
Composed models (using all-of, one-of or any-of) are generated as "mixins" rather than using inheritance, to match openapi generator's behaviour. We therefore need to ensure models import all types from the composed properties. References #841
I've raised #845 to fix these 3 issues! Note that the Are you returning any default responses from your API in your use case? I'm curious to know whether you're actually using the generated code for the default response, as it doesn't seem to have ever matched the expected behaviour from the specification: https://swagger.io/docs/specification/v3_0/describing-responses/#default-response |
#845) * fix(type-safe-api): add missing imports for parameter models Parameter models were not being imported in the API client in the typescript runtime. References #841 * fix(type-safe-api): fix duplicate 200 response for operations with default responses OpenAPI generator treated "default" responses as responses with code 0, however parseOpenapi treats default as 200. Adjust code generation to follow OpenAPI for backwards compatibility and to avoid duplicate 200 responses. Note that this should be revisited such that code generation allows for any response code other than those defined to be returned for the default response, rather than 0. References #841 * fix(type-safe-api): add missing imports for composed models Composed models (using all-of, one-of or any-of) are generated as "mixins" rather than using inheritance, to match openapi generator's behaviour. We therefore need to ensure models import all types from the composed properties. References #841
Hi @cogwirrel, I never used the default 503 responses in my API handlers, but implemented it in api model as a best practice (by looking at recommendations and OpenAPI audit tools) |
Fixed in 0.23.60 thx a lot :) |
Cool that makes sense! Definitely better that the generated code compiles now but we should revisit what it looks like for default responses. I've raised #847 to track this :) |
Describe the bug
With a shared parameters directly under the path instead of the method (to share path ID for example for get, put, delete methods) the ID model is generated but not imported in the runtime Api.ts file.
For example with this OpenAPI file:
Expected Behavior
Path parameters should be handled same as method parameter
Current Behavior
HelloId
is correctly generated inmodels/HelloId.ts
but not imported inDefaultApi.ts
so build fail.Reproduction Steps
If you also try to uncomment default responses you'll also see another error, I use default in all my APIs for 503 responses and it worked before but now it is interpreted as 200 and cause a duplicate in
OperationConfig.ts
It is not the same issue so if needed i can report another issue for it
Possible Solution
No time to look at a solution sorry but I'm pretty sure something change in a recent version because I didn't have any issue in v0.23.49
Additional Information/Context
No response
PDK version used
v0.23.55
What languages are you seeing this issue on?
Typescript
Environment details (OS name and version, etc.)
macOS 14.6.1, apple m1 pro, node 20.18.0, pnpm 8.15.9
The text was updated successfully, but these errors were encountered: