blocking_in_async
Find blocking sync calls inside async Django endpoints that stall the event loop, including database calls and calls reached through project functions. Get the call path to fix the bottleneck.
Instructions
Synchronous calls that run on the event loop.
FastAPI runs an `async def` endpoint on the loop itself and a `def`
endpoint in a threadpool. So a blocking call inside `async def` does not
slow one request, it stops every request in the process - invisible at one
request a second, an outage at two hundred.
ruff's ASYNC rules cover open, time.sleep and subprocess inside an async
function. This adds the two that matter more: a synchronous database call,
which is the common one, and a blocking call reached through another
project function, where nothing at the call site looks blocking. The second
comes back with the path that reaches it.
Needs no Django. A `def` endpoint is never reported, because blocking in a
threadpool is fine and telling somebody to make it async causes the outage.
Args:
search_path: directory to scan. Defaults to the configured project.
follow_calls: also report blocking reached through a project function.
max_depth: how many calls deep to follow.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| max_depth | No | ||
| search_path | No | ||
| follow_calls | No |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||