Slow or failing async requests: execution and lifespan diagnosis

Understand the likely causes

• Likely causes include a blocking library called directly inside async code, excessive pool waits, a globally reused resource from another loop, missing lifespan management, or cleanup before a stream or background task finishes using the resource. A slow dependency or database lock can also resemble event-loop trouble, so do not assume the framework is the cause.

Locate the failing execution stage

Record pinned versions, endpoint and dependency declarations, the relevant client or session owner, and safe stage-level evidence. Separate connection acquisition, I/O wait, CPU work, serialization, response streaming, and task completion. Preserve the first useful exception without logging credentials or full payloads. A status of 200 before later work fails does not prove completion. Start from a minimal synthetic reproduction and one hypothesis rather than switching every function to async or adding workers until the symptom changes.

Inspect the actual blocking call chain

FastAPI dispatches supported synchronous operations and dependencies through its documented thread-pool behavior, but it does not intercept every helper called from async def. If the helper blocks, choose an appropriate async API or an explicit reviewed synchronous boundary. The second complete example offloads a pure helper and verifies thread separation without performing real blocking I/O. Also inspect pool saturation and downstream concurrency before treating more coroutines as the repair.

import threading
from fastapi import FastAPI
from fastapi.testclient import TestClient
from starlette.concurrency import run_in_threadpool
def helper(value, loop_thread):
    return {"value": value * 2, "same_thread": threading.get_ident() == loop_thread}
app = FastAPI()
@app.get("/calculate")
async def calculate():
    return await run_in_threadpool(helper, 3, threading.get_ident())
with TestClient(app) as client:
    print(client.get("/calculate").json())

{'value': 6, 'same_thread': False}

Make startup and client lifetime explicit

Construct application-wide resources inside the chosen lifespan and close them there. A test using TestClient should enter its context; an async ASGI transport needs explicit lifespan handling when startup resources matter. The first example verifies a synthetic resource exists during the request and is closed afterward. Do not create an async client on one loop and reuse it across unrelated test loops. Do not assume a global dictionary, connection, or cache is shared safely across workers.

from contextlib import asynccontextmanager
from fastapi import FastAPI
from fastapi.testclient import TestClient
state = {"closed": False}
@asynccontextmanager
async def lifespan(app):
    app.state.resource = {"ready": True}
    try:
        yield
    finally:
        state["closed"] = True
app = FastAPI(lifespan=lifespan)
@app.get("/resource")
def resource(): return app.state.resource
with TestClient(app) as client:
    print(client.get("/resource").json())
print(state["closed"])

{'ready': True}
True

Review response and task cleanup scope

A yielding dependency can close before a function-scoped response is sent, while request-scoped behavior can preserve the resource through response handling under the pinned framework rules. Match that to whether a stream still reads the resource. Background work should receive stable inputs and acquire its own resources rather than capture a closed request session. Do not hide a commit in cleanup after reporting durable success. Preserve the original failure when cleanup also fails, and keep all teardown bounded so a diagnostic or shutdown path cannot wait indefinitely.

Repair and verify one owned boundary

Change the narrow execution or lifetime contract supported by evidence, then test success, failure, cancellation, streaming where relevant, and teardown. Use explicit completion signals rather than arbitrary sleeps. These scripts use only in-process TestClient, synthetic state, and a pure helper; they open no server and contact no network or configured database. Real driver performance and deployment behavior require separate authorized integration work.

Keep it from recurring

• Review execution and resource lifetime together, use app factories and isolated fixtures, and keep pool, queue, and deadline budgets explicit. Recheck dependency cleanup and client behavior on upgrades. Avoid global async clients with unclear loop ownership and background tasks that borrow request-owned sessions.