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

[sergioestebance]

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 Support non standard http codes #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.