swagger-api / swagger-api/swagger-codegen
Code generation bug in parameters required checking
Nobody has claimed this yet.
- Dominant language
- Mustache
- Stars
- 17.8k
- Forks
- 6k
- PR merge metrics
- No merged PRs in 30d
Description
"requestBody" : {
"content" : {
"application/x-www-form-urlencoded" : {
"schema" : {
"$ref" : "#/components/schemas/Parameter"
}
}
}
}
...
"components" : {
"schemas" : {
"Parameter" : {
"type" : "object",
"required" : [ "id" ],
"properties" : {
"id" : {
"type" : "string",
"description" : "Application Name that you have configured in your Enterprise Account when configuring the integration options."
}
}
}
}
}
Tested in context of : "library" set to "okhttp-gson".
- Even "id" is set required in specification, but such parameter is taken as optional and no validation is done prior a call in generated "api class".
- I would like to suggest if it could be used even as option to use entire object in call to avoid that code rewrite for new added optional parameter.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the okhttp-gson generator entry points and the generated API class described in the report, then reproduce the required-field behavior using the supplied OpenAPI schema. Check how the required id in Parameter is represented before a call; done means the generated client handles that required field as specified, with the object-based call option clarified or implemented if in scope.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, openapi
- Domain
- api, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100