flask raising HTTPException does not cause

The Fix

Upgrade to version 2.0.0 or later.

Based on closed pallets/flask issue #3851 · 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

@@ -440,18 +440,32 @@ The following signals exist in Flask:
 .. data:: got_request_exception
 
-   This signal is sent when an exception happens during request processing.
-   It is sent *before* the standard exception handling kicks in and even
-   in debug mode, where no exception handling happens.  The exception

repro.py

from flask import Flask, got_request_exception, abort
app = Flask(__name__)

def signal_handler(sender, exception, **extra):
    print("handled %s" % str(type(exception)))

got_request_exception.connect(signal_handler)

@app.route('/1')
def view_1():
    # calling this view prints "handled <class 'RuntimeError'>" to the console
    raise RuntimeError()

@app.route('/2')
def view_2():
    # calling this view prints nothing
    abort(400)
    # raise werkzeug.exception.TooManyRequests
    # e.g. also does nothing

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 2.0.0 or later.\nWhen NOT to use: This fix is not applicable if you require HTTPExceptions to be treated as unhandled.\n\n

Why This Fix Works in Production

Trigger: raising HTTPException does not cause got_request_exception signal to be emitted
Mechanism: Raising HTTPException does not trigger the got_request_exception signal due to its handling in Flask
Why the fix works: Updated documentation to clarify that the got_request_exception signal is not sent for HTTPException or other handled exceptions. (first fixed release: 2.0.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

Raising HTTPException does not trigger the got_request_exception signal due to its handling in Flask
Surfaces as: raising HTTPException does not cause got_request_exception signal to be emitted

Proof / Evidence

GitHub issue: #3851
Fix PR: https://github.com/pallets/flask/pull/3883
First fixed release: 2.0.0
Reproduced locally: No (not executed)
Last verified: 2026-02-09
Confidence: 0.85
Did this fix it?: Yes (upstream fix exists)
Own content ratio: 0.59

Discussion

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

Jump to Sources Open on GitHub

“@tonydelanuez happy to review a PR if you still have time”

@davidism · 2021-01-29 · source

“You really don't want to disable TRAP_HTTP_EXCEPTIONS, that will cause all HTTPException to be treated as 500 errors, it's only intended for some testing and…”

@davidism · 2021-02-02 · source

“Nice find”

@tonydelanuez · 2021-01-01 · source

Failure Signature (Search String)

raising HTTPException does not cause got_request_exception signal to be emitted

Error Message

Stack trace

error.txt

Error Message
-------------
raising HTTPException does not cause got_request_exception signal to be emitted

Minimal Reproduction

repro.py

from flask import Flask, got_request_exception, abort
app = Flask(__name__)

def signal_handler(sender, exception, **extra):
    print("handled %s" % str(type(exception)))

got_request_exception.connect(signal_handler)

@app.route('/1')
def view_1():
    # calling this view prints "handled <class 'RuntimeError'>" to the console
    raise RuntimeError()

@app.route('/2')
def view_2():
    # calling this view prints nothing
    abort(400)
    # raise werkzeug.exception.TooManyRequests
    # e.g. also does nothing

What Broke

Signal handlers for exceptions are not called, leading to missing error logging.

Why It Broke

Raising HTTPException does not trigger the got_request_exception signal due to its handling in Flask

Fix Options (Details)

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

Upgrade to version 2.0.0 or later.

When NOT to use: This fix is not applicable if you require HTTPExceptions to be treated as unhandled.

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

Fix reference: https://github.com/pallets/flask/pull/3883

First fixed release: 2.0.0

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

When NOT to Use This Fix

This fix is not applicable if you require HTTPExceptions to be treated as unhandled.

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

Track RSS + object counts after deployments; alert on monotonic growth and GC pressure.
Add a long-running test that repeats the failing call path and asserts stable memory.
Make timeouts explicit and test them (unit + integration) to avoid silent behavior changes.
Instrument retries (attempt count + reason) and alert on spikes to catch dependency slowdowns.

Version Compatibility Table

Version	Status
2.0.0	Fixed

Related Issues

No related fixes found.

Cluster: flask:configuration-error All hubs All clusters

Related clusters: Data consistency Other Duplicate processing

Sources

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

flask raising HTTPException does not cause got_request_exception signal to be emitted (Fix)