Model import shadows HTTP `Client` import when a schema is named `Client`
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 70/100
Research direction
Start with endpoint_module.py.jinja and the logic behind endpoint.relative_imports, then generate the minimal OpenAPI specification from the issue. Check the generated api/client/update_client.py imports and the _parse_response and _build_response annotations. Done means a schema named Client no longer causes the HTTP Client reference to be shadowed.
Written by the indexing model from the issue text.
Description
Describe the bug
When an OpenAPI spec contains a schema named Client, the generated endpoint modules import both the HTTP Client class and the Client model class under the same name. The model import silently shadows the HTTP client import, making Client in type annotations refer to the wrong class.
endpoint_module.py.jinja unconditionally emits:
from ...client import AuthenticatedClient, Client
Then endpoint.relative_imports adds model imports. When a model is also named Client, the result is:
from ...client import AuthenticatedClient, Client # HTTP client
from ...models.client import Client # model — shadows the line above
This causes Client in _parse_response and _build_response type annotations to resolve to the model instead of the HTTP client class.
OpenAPI Spec File
Minimal reproduction:
openapi: "3.0.3"
info:
title: Minimal repro
version: "1.0"
paths:
/api/clients/{id}:
patch:
operationId: update_client
tags:
- client
parameters:
- name: id
in: path
required: true
schema:
type: string
requestBody:
content:
application/json:
schema:
type: object
properties:
name:
type: string
responses:
"200":
description: OK
content:
application/json:
schema:
$ref: "#/components/schemas/Client"
components:
schemas:
Client:
type: object
properties:
name:
type: string
In the generated api/client/update_client.py, line 6 imports Client from ...client and line 10 re-imports Client from ...models.client, shadowing it.
Desktop (please complete the following information):
- OS: macOS 15 (ARM64)
- Python Version: 3.13
- openapi-python-client version: 0.27.1 (also verified on 0.28.3)
Additional context
We worked around this by using custom templates.
- 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 ·