Multiple body-types in an endpoint with same model (referenced via `$ref`) results in ambiguity in generated code
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
Research direction
Start by tracing how the generator handles the OpenAPI requestBody content entries and produces the generated _get_kwargs function. Reproduce the issue with the provided JSON snippet, then add coverage for both application/json and multipart/form-data; done means the generated client selects the correct body handling without ambiguous identical conditions.
Written by the indexing model from the issue text.
Description
| Python Version | OpenAPI Client Generator Version |
|---|---|
| 3.11.6 | 0.18.0 |
Actual Behavior
When an endpoint has multiple body types, each referencing the same model (via a $ref key), the generator generates the same class name for each body types, which results then in the following generated code:
def _get_kwargs(
# ...
):
# ...
if isinstance(body, WritableJournalEntryRequest):
_json_body = body.to_dict()
_kwargs["json"] = _json_body
headers["Content-Type"] = "application/json"
if isinstance(body, WritableJournalEntryRequest):
_files_body = body.to_multipart()
_kwargs["files"] = _files_body
headers["Content-Type"] = "multipart/form-data"
# ...
As you can see, both if-statement's conditions will resolve to True, therefore only the last body type will be used.
Desired Behavior
The body-type should be part of the generated class name to avoid such ambiguities.
Or an if/elseif/else should be used in the template (which would result in the first one being applied ONLY).
OpenAPI Spec File
The OpenAPI spec is from Netbox, but here is the relevant snippet:
"requestBody": {
"content": {
"application/json": {
"schema": {
"$ref": "#/components/schemas/WritableJournalEntryRequest"
}
},
"multipart/form-data": {
"schema": {
"$ref": "#/components/schemas/WritableJournalEntryRequest"
}
}
},
"required": true
},
- Dominant language
- Python
- Stars
- 2k
- Forks
- 293
- Avg merge
- 34m
- Merged PRs (30d)
- 1
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.
More from openapi-generators/openapi-python-client
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 3/5 1-2 days Newbie friendliness 72/100
openapi-generators/openapi-python-client#1451 · 1 comment ·
-
Difficulty 3/5 1-2 days Newbie friendliness 52/100
-
Difficulty 3/5 1-2 days Newbie friendliness 64/100
openapi-generators/openapi-python-client#1435 · 1 comment ·
All issues in openapi-generators/openapi-python-client
Similar issues
-
essnmx good first issue
Difficulty 1/5 Under an hour Newbie friendliness 95/100
-
[Feature] 奇物选择添加优先级 Open
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
syfoud/Simulated_Scepter#174 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Giskard-AI/giskard-oss#2840 · 1 comment ·
-
A claim comment carrying the issue number is silently declined while the workflow reports success Openarea: repo bug perceived difficulty: 2
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
yeti-platform/yeti#1380 ·