Can a Flask view detect that the client disconnected and stop long-running work early?

Short answer

No — there is no documented, server-independent way for a Flask view to receive a cancellation signal mid-request. Under WSGI (Gunicorn sync workers, your stated setup), the worker thread keeps executing the view after the client disconnects; the disconnect is usually only noticed when the server tries to write the response. request.is_disconnected is a best-effort, server-dependent check, not a cancellation primitive. True cancellation requires running as a real ASGI application, and even then it only interrupts at await points.

Why WSGI sync workers can't help

The WSGI contract has no channel for the server to tell your application "the client went away." Gunicorn's sync worker calls your view and waits for a return value. If the socket closes meanwhile, nothing interrupts the Python code — the failure surfaces later as a write error when the response is sent. This is protocol-level, not a Flask limitation you can configure around.

Polling request.is_disconnected: useful, but not a contract

Werkzeug's request.is_disconnected attempts a non-blocking read on the underlying socket to see if the peer closed the connection. Polling it between chunks of work is a pragmatic early-exit pattern:

from flask import request

@app.route("/report")
def report():
    for chunk in generate_report_chunks():
        if request.is_disconnected():
            app.logger.info("client gone, aborting")
            return "", 499  # never actually delivered
        process(chunk)
    return send_file(output)

It often works with Gunicorn sync workers on direct connections, but treat it as an optimization, not a guarantee:

• Behind a buffering reverse proxy (some nginx configurations), the proxy may not propagate the disconnect promptly, so the flag may lag or never flip.
• Behavior is sensitive to your exact Werkzeug and Gunicorn versions — verify on your stack (see below).
• Wrap expensive work in try/finally so temp files and DB transactions are cleaned up even when the work runs to completion for nobody.

Async views and ASGI: what actually changes

Converting to async def under standard Flask does not deliver cancellation. Flask 2.x/3.x bridges async views into the sync WSGI context, so no ASGI http.disconnect event ever reaches your code. To get real cancellation you must serve the app as a genuine ASGI application — via Hypercorn/Uvicorn with an ASGI wrapper, or by moving to Quart. Then the server can surface the disconnect and cancel the task, raising asyncio.CancelledError in the view.

Caveats, and they matter for your 30–60 second workloads:

• CancelledError is only delivered at await points. CPU-bound loops, synchronous DB drivers, and time.sleep block the event loop and cannot be interrupted — the work must be awaited cooperatively or offloaded to threads/processes with explicit cancellation checks.
• Exact disconnect semantics (task cancellation vs. merely delivering http.disconnect on the receive channel) vary between Hypercorn, Uvicorn, and Daphne — confirm on the server you choose.

The robust fix for 30–60s work

For operations this long, the architecture-level answer is to get them out of the request/response cycle: enqueue a Celery/RQ job, return 202 with a job ID, and let the client poll or receive a webhook. The job checks a cancellation flag the client sets explicitly or on disconnect. This works identically on every server and survives proxies, retries, and page reloads.

How to verify on your stack

1. Write a test view that sleeps in a loop, polling request.is_disconnected and logging the result.
2. Start a request with curl, kill it mid-request (Ctrl-C), and check whether and when the flag flips under your Gunicorn setup.
3. Repeat with your production proxy in front — this is the step most people skip, and where the pattern usually breaks.
4. If evaluating ASGI: wrap the app for Hypercorn, make the view async with await asyncio.sleep(...), cancel the client, and confirm CancelledError fires and your finally cleanup runs.

Behavioral details here are version- and server-sensitive; run the verification steps against your exact Werkzeug/Gunicorn/proxy combination before relying on disconnect detection in production.