⚡ Bolt: Offload CPU-bound bcrypt operations to threadpool - #113
Conversation
In FastAPI, running CPU-bound tasks like password hashing/verification synchronously blocks the entire event loop, destroying concurrency. This change offloads these operations to `starlette.concurrency.run_in_threadpool`. Co-authored-by: benpiper <4343814+benpiper@users.noreply.github.com>
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
💡 What
Updated
backend/auth.pyto offload CPU-boundbcrypt.hashpwandbcrypt.checkpwoperations to the background threadpool usingstarlette.concurrency.run_in_threadpool. Madeverify_passwordandget_password_hashasynchronous, and updated all call sites inbackend/main.pyandbackend/auth.pytoawaitthem. Added an entry to.jules/bolt.mdrecording this pattern.🎯 Why
In FastAPI/Starlette, asynchronous routes and event loops are designed for I/O bounds. When CPU-bound tasks (like
bcrypt, which is intentionally slow by design, often taking hundreds of milliseconds) are run directly on the event loop, they block it entirely. This means during a login or registration request, all other concurrent requests to the API stall until the hash completes. Moving these to a threadpool frees up the main event loop to handle other requests concurrently.📊 Impact
Increases API throughput and concurrency under load. Background tasks and other API endpoints will no longer be stalled for ~100-300ms during every login/registration attempt.
🔬 Measurement
Tests were run via
cd backend && uv run pytest tests/to confirm functionality remains unchanged. Manual timing scripts (like the one implemented during exploration) show background task iterations jumping from ~44 to ~140 during 3 concurrent login simulations, showing the event loop remains unblocked.PR created automatically by Jules for task 14360453699703027549 started by @benpiper