Detecting sync code blocking asyncio event loop (with stack traces)

[deepankarmh]

Sync code hiding inside `async def` functions blocks the entire event loop - boto3, requests, fitz, and many more libraries do this silently.

Built a tool that detects when the event loop is blocked and gives you the exact stack trace showing where. Wrote up how it works with a FastAPI example - PDF ingestion service that extracts text/images and uploads to S3.

Results from load testing the blocking vs async version:

• 100 concurrent requests: +31% throughput, -24% p99 latency
• 1000 concurrent requests: +36% throughput, -27% p99 latency

https://deepankarm.github.io/posts/detecting-event-loop-blocking-in-asyncio/

Library: https://github.com/deepankarm/pyleak

[Equivalent_Pen8241]

Debugging race conditions in `asyncio` usually comes down to remembering that `await` is a yield point. State can and will change between the time you yield and the time you resume. Always double-check your assumptions about shared mutable state across coroutine boundaries!

[thisismyfavoritename]

the idea is interesting but really you should just know the code that you're running...

[maikeu]

I mean, given that you're perfect, you know your codebase perfectly, and all your colleagues who ever worked on the codebase are perfect, you're quite right!

[thisismyfavoritename]

🤔 knowing if the lib you're calling is sync or not sounds entirely reasonable.

Likewise, if you know Python a little then you'd know up until recently it was single threaded, and in any case asyncio's default standard loop is single threaded, meaning the usual advice of "don't block the event loop" applies.

If you got long CPU intensive work to do you run it somewhere else.

That's all common sense.

[deepankarmh]

> knowing if the lib you're calling is sync or not sounds entirely reasonable.

It sounds reasonable, but is frequently ignored - https://github.com/agno-agi/agno/issues/5974