_build_response crashes with ValueError on non-IANA HTTP status codes (520, 561, etc.)

Describe the bug

The generated _build_response function unconditionally calls HTTPStatus(response.status_code) to populate Response.status_code. Python's http.HTTPStatus is a closed IntEnum covering only IANA-registered codes — passing anything else raises ValueError: <n> is not a valid HTTPStatus.

This means any endpoint generated by openapi-python-client crashes whenever the network returns a non-IANA code, including:

• Cloudflare 520–527 (origin errors — extremely common when there's an upstream hiccup)
• AWS WAF 561
• nginx 499 (client closed request)
• Any proxy / CDN / origin that emits a custom code

The crash hits before any response handler runs, so even users who set raise_on_unexpected_status=True get a ValueError rather than an UnexpectedStatus exception they can catch.

Reproduction

from http import HTTPStatus
HTTPStatus(520)
# ValueError: 520 is not a valid HTTPStatus

Any generated endpoint module reproduces it:

# templates/endpoint_module.py.jinja, line 97
def _build_response(*, client, response):
    return Response(
        status_code=HTTPStatus(response.status_code),  # <-- crashes here on 520
        ...
    )

An httpx response with a 520 status from a Cloudflare-fronted origin will trip this on every call. No OpenAPI spec change is required — the bug is in the template, not the spec.

Expected behavior

_build_response should tolerate non-IANA codes — either by widening Response.status_code to HTTPStatus | int and falling back to the raw int, or by raising UnexpectedStatus with the raw code. Either is better than ValueError.

Desktop

• OS: macOS 15
• Python Version: 3.12
• openapi-python-client version: 0.28.4 (latest at time of filing — bug present from at least 0.20.x onward)

Related

• PR #1407 ("Support non standard http codes") proposes an opt-in allow_int_response_codes flag. Filing this issue so the bug has a permanent searchable record and so the safer behavior can be considered as the default (since the current behavior crashes the generated client on transient upstream errors users can't influence).

Workaround

For others hitting this: override the endpoint_module.py.jinja and types.py.jinja templates via --custom-template-path, replacing the HTTPStatus(...) call with a try/except that falls back to the raw int.

檢視 templates/endpoint_module.py.jinja 和 types.py.jinja，從 issue 中顯示的 HTTPStatus 轉換開始。將這些替代方案與相關的 PR #1407 進行比較，並確認對非 IANA 回應碼的預期處理方式；完成的標準是產生的端點在回應處理之前不再引發 ValueError，且所選的狀態碼行為已獲得涵蓋。