Will It Vibe?Blocking requests call inside an async function
Part of Code Quality & Syntax, which counts for 20% of the overall score. When this check fires it deducts 8 points from that category, once per scan, no matter how many places it turns up.
What it detects
requests.get/post/etc. make a real thread-blocking network call, stalling the event loop for the full round trip of the request.
Why it matters
The requests library makes a real, thread-blocking network call, so calling requests.get, requests.post, or similar inside an async function stalls the entire event loop for the full round trip time of that HTTP request, exactly like time.sleep() would. Every other coroutine scheduled on the same loop, other requests, background tasks, health checks, waits behind it, so a single slow upstream API call can make an otherwise healthy async service look completely unresponsive.
How to fix it
Use an async-native HTTP client instead, such as httpx.AsyncClient or aiohttp, and await the call: response = await client.get(url). If migrating the whole codebase off requests is not practical right now, at minimum wrap the specific blocking call in loop.run_in_executor(None, requests.get, url) so it runs in a thread instead of on the event loop.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo