| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Add try/except in _build_response so that non-IANA status codes (e.g. 520 Cloudflare, 561 AWS WAF, 499 nginx) fall back to raw int instead of raising ValueError from HTTPStatus(). Fixes openapi-generators#1442
Widen Response.status_code type from HTTPStatus to HTTPStatus | int so generated clients don't crash with ValueError on vendor-specific status codes like 520 (Cloudflare), 561 (AWS WAF), or 499 (nginx). Fixes openapi-generators#1442
|
Hi 👋 — just checking in on this PR. It's been open for a few months with no feedback and I want to make sure it's still on the radar. The fix is small (2 files, 7 lines) and addresses a real crash that affects anyone whose server returns a non-IANA status code like Cloudflare's 520 or AWS WAF's 561. The approach — try/except fallback on HTTPStatus(response.status_code) — is consistent with how similar libraries handle this. Happy to address any review comments or rebase if needed. Thanks! |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Problem
Generated clients crash with ValueError when the server returns a non-IANA HTTP status code such as:
The crash happens inside _build_response in every generated endpoint module:
http.HTTPStatus is a closed IntEnum — it only accepts IANA-registered codes. Any code outside that set raises ValueError.
This is a silent runtime failure: users see an unhandled exception even though their API call succeeded.
Fixes #1442.
Changes
openapi_python_client/templates/endpoint_module.py.jinja
Replace the bare HTTPStatus(response.status_code) call with a try/except that falls back to the raw integer:
openapi_python_client/templates/types.py.jinja
Widen the Response.status_code type annotation to accept both known and unknown codes:
Why this approach?
Testing
To reproduce the crash before this fix:
After the fix, _build_response returns a Response with status_code=520 (plain int) instead of raising.