Footgun - using Request directly in a sync route can cause thread to get stuck forever #14893

krmozejko · 2026-02-11T10:34:03Z

krmozejko
Feb 11, 2026

First Check

I added a very descriptive title here.
I used the GitHub search to find a similar question and didn't find it.
I searched the FastAPI documentation, with the integrated search.
I already searched in Google "How to X in FastAPI" and didn't find any information.
I already read and followed all the tutorial in the docs and didn't find an answer.
I already checked if it is not related to FastAPI but to Pydantic.
I already checked if it is not related to FastAPI but to Swagger UI.
I already checked if it is not related to FastAPI but to ReDoc.

Commit to Help

I commit to help with one of those options 👆

Example Code

# server.py
from contextlib import asynccontextmanager

import anyio
import uvicorn
from anyio import to_thread
from fastapi import FastAPI
from starlette.requests import Request


@asynccontextmanager
async def lifespan(app):
    # limit threadpool size to only one worker
    anyio.to_thread.current_default_thread_limiter().total_tokens = 1
    yield
app = FastAPI(lifespan=lifespan)


@app.post("/async")
async def async_(request: Request):
    payload = await request.body()
    return {"async_message": payload}


@app.post("/sync_one")
def sync_one(request: Request):
  # Correct way to call request.body from sync routes
  payload = anyio.from_thread.run(request.body)
  return {"sync_one_message": payload}


@app.post("/sync_two")
def sync_two(request: Request):
    # Wrong way to call request.body from sync routes
    payload = anyio.run(request.body)
    return {"sync_two_message": payload}


if __name__ == "__main__":
    uvicorn.run(app, host="0.0.0.0", port=8000)


# test.py
from time import sleep

import requests

# all routes work fine
print("================\nregular request\n================")
print(requests.post("http://localhost:8000/async", data=b"hello world").json())
print(requests.post("http://localhost:8000/sync_one", data=b"hello world").json())
print(requests.post("http://localhost:8000/sync_two", data=b"hello world").json())

# let's test chunked request
def chunked_generator():
    yield b'we may have'
    sleep(0.2)
    yield b' slow connection'

print("================\nchunked request\n================")
# no problem with async
print(requests.post("http://localhost:8000/async", data=chunked_generator()).json())
# no problem with sync_one
print(requests.post("http://localhost:8000/sync_one", data=chunked_generator()).json())

# but sync_two hangs indefinitely
try:
    requests.post("http://localhost:8000/sync_two", data=chunked_generator(), timeout=1)
except requests.exceptions.ReadTimeout:
    print("Oops, sync_two got stuck")

# and all sync routes stopped responding
try:
    requests.post("http://localhost:8000/sync_one", data=b"hello world", timeout=1)
except requests.exceptions.ReadTimeout:
    print("We have a problem here...")

# at this point threadpool thread is stuck, server will never be able to process any sync route
# but async still works
print(requests.post("http://localhost:8000/async", data=b"hello world").json())

Description

I came across this issue in a real-world code. It stayed hidden for quite some time and it suddenly blew up when one app started to be under sustained load.

The following Request methods:

request.body()
request.json()
request.form()
request.stream()

read from underlying stream. Calling such method from a sync route with use of anyio.run can cause the whole thread to get indefinitely stuck.
It happens because anyio.run() creates a NEW event loop in the worker thread, separate from the main event loop. The Request stream uses asyncio synchronization primitives (like asyncio.Event) that are bound to the MAIN event loop. When the worker thread's event loop awaits message_event.wait(), it's waiting for an event that will be set in a DIFFERENT event loop, so they never communicate.

It is nasty, because it "sometimes works". If at the time of such call whole body has already been read by main thread's event loop - all works great. But it is not always the case - if payload is too large to be read at once or connection is slow or traffic is large and keeps main event loop busy, then our worker thread will await message_event.wait() - event which is set in a different thread's event loop. It makes worker thread wait for an event that will never happen in it's world.

I am (now) aware that it is a misuse of anyio. In this case one should use anyio.from_thread.run instead of anyio.run to delegate call of async function to main thread's event loop instead of creating a new, local one.
But that requires deeper knowledge of how FastAPI uses anyio to handle sync routes.

A web developer may want to do something like this:

@app.post("/sync")
def some_route(request: Request):
    if request.headers["Content-Type"] == "multipart/form-data":
        data = request.form()
    else:
        data = request.json()
    # do something smart

Of course that won't work, so a dev will ask google/chatgpt/claude how to call async method from sync code. He will probably get a suggestion to use anyio.run or asyncio.run. That will work in tests, probably will work on dev, but has potential to blow up on production under load.

I think it would be good to either document how to call async code from sync routes properly or to provide a utility for that which would abstract use of anyio away. Without that it is easy to shoot oneself in the foot.

Operating System

macOS

Operating System Details

No response

FastAPI Version

0.128.6

Pydantic Version

2.12.5

Python Version

3.13

Additional Context

No response

juni2003 · 2026-02-12T05:21:37Z

juni2003
Feb 12, 2026

You're right this is a footgun. The issue is that when you call request.body(), request.json(), request.form(), or request.stream() from a sync route using anyio.run() or asyncio.run(), you create a new event loop in the worker thread. But the Request object's async primitives (like asyncio.Event) are tied to the main event loop. The two loops never communicate, causing indefinite hangs when chunked/slow requests come in.

Try this:

import anyio
@app.post("/sync")
def some_route(request: Request):
    #
    data = anyio.from_thread.run(request.json)
    # or
    body = anyio.from_thread.run(request.body)

Here anyio.from_thread.run() delegates the async call back to the main event loop where FastAPI is running instead of creating a new one. So try this maybe this will solve your problem.

1 reply

krmozejko Feb 12, 2026
Author

Yes, that's the proper way to do it and it solves the problem. I have it in the example code.

YuriiMotov · 2026-02-12T06:49:13Z

YuriiMotov
Feb 12, 2026
Collaborator

I think it would be good to either document how to call async code from sync routes properly or to provide a utility for that which would abstract use of anyio away.

I agree we should describe this in docs

0 replies

This comment was marked as spam.

Sign in to view

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Footgun - using Request directly in a sync route can cause thread to get stuck forever #14893

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 4 comments 1 reply

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

This comment was marked as spam.

This comment was marked as spam.

Select a reply

Uh oh!

Uh oh!

Footgun - using Request directly in a sync route can cause thread to get stuck forever #14893

Uh oh!

Uh oh!

krmozejko Feb 11, 2026

First Check

Commit to Help

Example Code

Description

Operating System

Operating System Details

FastAPI Version

Pydantic Version

Python Version

Additional Context

Replies: 4 comments · 1 reply

Uh oh!

juni2003 Feb 12, 2026

Uh oh!

krmozejko Feb 12, 2026 Author

Uh oh!

YuriiMotov Feb 12, 2026 Collaborator

This comment was marked as spam.

This comment was marked as spam.

krmozejko
Feb 11, 2026

Replies: 4 comments 1 reply

juni2003
Feb 12, 2026

krmozejko Feb 12, 2026
Author

YuriiMotov
Feb 12, 2026
Collaborator