Bug Report: Incorrect Model Reference in Generated Paginated Envelope
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
Research direction
Start with the provided schema.yaml and reproduce the generation command using the two paginated envelope definitions. Inspect the generated PaginatedTransactionEnvelope and compare its data type and deserialization imports with the schema and the correctly generated customer envelope. Done means transaction data resolves to TransactionEntity without the CustomerEntity status error.
Written by the indexing model from the issue text.
Description
Bug Report: Incorrect Model Reference in Generated Paginated Envelope
Summary
openapi-python-client incorrectly generates PaginatedTransactionEnvelope with CustomerEntity instead of TransactionEntity, despite the OpenAPI schema correctly specifying TransactionEntity.
Environment
- openapi-python-client version: 0.28.1
- Python version: 3.13
- Generation command:
openapi-python-client generate \ --path schema.yaml \ --output-path ./generated \ --meta none
Expected Behavior
The generated PaginatedTransactionEnvelope should use TransactionEntity based on this schema definition:
PaginatedTransactionEnvelope:
allOf:
- $ref: '#/components/schemas/PaginatedSuccessEnvelope'
- type: object
properties:
data:
type: array
items:
$ref: '#/components/schemas/TransactionEntity'
Expected generated code:
if TYPE_CHECKING:
from ..models.transaction_entity import TransactionEntity
from ..models.links import Links
@_attrs_define
class PaginatedTransactionEnvelope:
timestamp: datetime.datetime
path: str
data: list[TransactionEntity] # ✓ Correct
links: Links
Actual Behavior
The generator produces code using CustomerEntity instead:
if TYPE_CHECKING:
from ..models.customer_entity import CustomerEntity # ✗ Wrong!
from ..models.links import Links
@_attrs_define
class PaginatedTransactionEnvelope:
timestamp: datetime.datetime
path: str
data: list[CustomerEntity] # ✗ Wrong!
links: Links
@classmethod
def from_dict(cls: type[T], src_dict: Mapping[str, Any]) -> T:
from ..models.customer_entity import CustomerEntity # ✗ Wrong!
from ..models.links import Links
# ...
for data_item_data in _data:
data_item = CustomerEntity.from_dict(data_item_data) # ✗ Wrong!
data.append(data_item)
Impact
This causes runtime errors when parsing API responses:
ValueError: 'failed' is not a valid CustomerEntityStatus
The parser attempts to deserialize transaction data as customer data, failing when transaction-specific status values don't exist in the CustomerEntityStatus enum.
Additional Context
The schema also defines PaginatedCustomerEnvelope (which correctly uses CustomerEntity). The generator may be incorrectly reusing or caching the entity type across similar paginated envelope structures.
Related schema definitions:
PaginatedCustomerEnvelope:
allOf:
- $ref: '#/components/schemas/PaginatedSuccessEnvelope'
- type: object
properties:
data:
type: array
items:
$ref: '#/components/schemas/CustomerEntity'
PaginatedTransactionEnvelope:
allOf:
- $ref: '#/components/schemas/PaginatedSuccessEnvelope'
- type: object
properties:
data:
type: array
items:
$ref: '#/components/schemas/TransactionEntity'
Workaround
We've added a post-generation fix script:
sed -i '' 's/from ..models.customer_entity import CustomerEntity/from ..models.transaction_entity import TransactionEntity/g' "$FILE"
sed -i '' 's/list\[CustomerEntity\]/list[TransactionEntity]/g' "$FILE"
sed -i '' 's/CustomerEntity\.from_dict/TransactionEntity.from_dict/g' "$FILE"
Reproduction
The issue appears when:
- Multiple paginated envelopes are defined using
allOfwith shared base schemas - Each envelope should use different entity types in the
dataarray - The generator confuses the entity types between envelopes
- 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 ·