Jump to solution
Verify

The Fix

Upgrade to version 0.14.0 or later.

Based on closed encode/httpx issue #1108 · PR/commit linked

Production note: Most teams hit this during upgrades or environment changes. Roll out with a canary and smoke critical endpoints (health, OpenAPI/docs) before 100%.

Jump to Verify Open PR/Commit
@@ -1,32 +1,33 @@ Our exception hierarchy: -* RequestError - + TransportError - - TimeoutException
repro.py
try: r = httpx.get('https://httpbin.org/status/400') r.raise_for_status() except httpx.HTTPError as error: print(error)
verify
Re-run the minimal reproduction on your broken version, then apply the fix and re-run.
fix.md
Option A — Upgrade to fixed release\nUpgrade to version 0.14.0 or later.\nWhen NOT to use: This fix should not be used if you require strict separation of exception types for error handling.\n\n

Why This Fix Works in Production

  • Trigger: Should HTTPError be a base class for RequestError and HTTPStatusError?
  • Mechanism: HTTPError was not a base class for RequestError and HTTPStatusError, causing confusion in exception handling
  • Why the fix works: Keeps HTTPError as a base class for RequestError and HTTPStatusError, ensuring existing code continues to work as expected while providing finer-grained exception handling. (first fixed release: 0.14.0).
Production impact:
  • If left unfixed, the same config can fail only in production (env differences), causing startup failures or partial feature outages.

Why This Breaks in Prod

  • Triggered by an upgrade/regression window: 3.7 breaks; 0.14.0 is the first fixed release.
  • HTTPError was not a base class for RequestError and HTTPStatusError, causing confusion in exception handling
  • Surfaces as: Should HTTPError be a base class for RequestError and HTTPStatusError?

Proof / Evidence

  • GitHub issue: #1108
  • Fix PR: https://github.com/encode/httpx/pull/1125
  • First fixed release: 0.14.0
  • Affected versions: 3.7
  • Reproduced locally: No (not executed)
  • Last verified: 2026-02-09
  • Confidence: 0.75
  • Did this fix it?: Yes (upstream fix exists)
  • Own content ratio: 0.82

Discussion

High-signal excerpts from the issue thread (symptoms, repros, edge-cases).

“That's a really interesting idea, thanks! An alternative might be to keep it as an exception class, as a base class of RequestError and HTTPStatusError?”
@lovelydinosaur · 2020-07-31 · source
“Would need to include all the top-level exceptions from https://github.com/encode/httpx/pull/1095, so: python HTTPError = (HTTPStatusError, RequestError, NotRedirectResponse, CookieConflict, StreamError)”
@StephenBrown2 · 2020-07-31 · source
“Actually, yeah, an exception class is probably better, you could probably do something to print out a deprecation warning that way?”
@iwoloschin · 2020-07-31 · source
“> An alternative might be to keep it as an exception class, as a base class of RequestError and HTTPStatusError? I'd support this option.”
@StephenBrown2 · 2020-07-31 · source

Failure Signature (Search String)

  • Should HTTPError be a base class for RequestError and HTTPStatusError?

Error Message

Stack trace
error.txt
Error Message ------------- Should HTTPError be a base class for RequestError and HTTPStatusError?

Minimal Reproduction

repro.py
try: r = httpx.get('https://httpbin.org/status/400') r.raise_for_status() except httpx.HTTPError as error: print(error)

What Broke

Existing code that catches HTTPError fails to handle HTTPStatusError, leading to unhandled exceptions.

Why It Broke

HTTPError was not a base class for RequestError and HTTPStatusError, causing confusion in exception handling

Fix Options (Details)

Option A — Upgrade to fixed release Safe default (recommended)

Upgrade to version 0.14.0 or later.

When NOT to use: This fix should not be used if you require strict separation of exception types for error handling.

Use when you can deploy the upstream fix. It is usually lower-risk than long-lived workarounds.

Fix reference: https://github.com/encode/httpx/pull/1125

First fixed release: 0.14.0

Last verified: 2026-02-09. Validate in your environment.

Get updates

We publish verified fixes weekly. No spam.

Subscribe

When NOT to Use This Fix

  • This fix should not be used if you require strict separation of exception types for error handling.

Verify Fix

verify
Re-run the minimal reproduction on your broken version, then apply the fix and re-run.

Did This Fix Work in Your Case?

Quick signal helps us prioritize which fixes to verify and improve.

Prevention

  • Add a CI check that diffs key outputs after upgrades (OpenAPI schema snapshots, JSON payload shapes, CLI output).
  • Upgrade behind a canary and run integration tests against the canary before 100% rollout.

Version Compatibility Table

VersionStatus
3.7 Broken
0.14.0 Fixed

Related Issues

No related fixes found.

Sources

We don’t republish the full GitHub discussion text. Use the links above for context.