When a requestBody lists multiple content types that all reference the same $ref schema, they all resolve to the same Python type. The generated _get_kwargs used a chain of if isinstance checks — but since
every branch matched, the last branch always won (typically multipart/form-data). It was impossible to make a JSON or form-urlencoded request.
# Generated (broken) — all three isinstance checks pass, multipart always winsifisinstance(body, DnsCreate):
_kwargs["json"] =body.to_dict()
headers["Content-Type"] ="application/json"ifisinstance(body, DnsCreate): # also matches!_kwargs["data"] =body.to_dict()
headers["Content-Type"] ="application/x-www-form-urlencoded"ifisinstance(body, DnsCreate): # also matches!_kwargs["files"] =body.to_multipart()
headers["Content-Type"] ="multipart/form-data"
Fix
When duplicate Python types are detected across bodies, a body_content_type: str parameter is emitted (defaulting to the first content type in the spec), and dispatch uses if/elif string comparisons instead of
isinstance checks.
Endpoints with distinct body types (the existing behaviour) are unaffected.
Changes
parser/openapi.py — adds bodies_with_content_type_dispatch (detects duplicate types) and unique_body_types (deduplicates for type annotations) properties to Endpoint
templates/endpoint_macros.py.jinja — adds body_content_type to arguments and kwargs macros when needed
templates/endpoint_module.py.jinja — uses if/elif string dispatch when bodies_with_content_type_dispatch is true
end_to_end_tests/functional_tests/generated_code_execution/test_endpoint_bodies.py — functional tests verifying correct dispatch for JSON, form-urlencoded, and multipart
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
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.
Fixes issue #1276
Problem
When a requestBody lists multiple content types that all reference the same $ref schema, they all resolve to the same Python type. The generated _get_kwargs used a chain of if isinstance checks — but since
every branch matched, the last branch always won (typically multipart/form-data). It was impossible to make a JSON or form-urlencoded request.
Fix
When duplicate Python types are detected across bodies, a body_content_type: str parameter is emitted (defaulting to the first content type in the spec), and dispatch uses if/elif string comparisons instead of
isinstance checks.
Endpoints with distinct body types (the existing behaviour) are unaffected.
Changes