_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，并且所选的状态码行为已得到覆盖。