Skip to content

⚡ Bolt: Unblock FastAPI event loop for higher concurrency#83

Open
Adityasingh-8858 wants to merge 1 commit into
mainfrom
bolt/async-event-loop-unblock-17820755677010460084
Open

⚡ Bolt: Unblock FastAPI event loop for higher concurrency#83
Adityasingh-8858 wants to merge 1 commit into
mainfrom
bolt/async-event-loop-unblock-17820755677010460084

Conversation

@Adityasingh-8858
Copy link
Copy Markdown
Collaborator

💡 What:

  • Replaced synchronous Groq client imports with AsyncGroq.
  • Updated Groq LLM generations in /ai-voice and /initiate-transfer to correctly await their network requests.
  • Offloaded all synchronous SQLite persistence database calls (create_transfer_record, list_transfers, set_agent_b, get_transfer) to a thread pool via await asyncio.to_thread.
  • Added performance tracking journal at .jules/bolt.md.

🎯 Why:
Synchronous network requests and database operations inside FastAPI async def endpoints block the event loop entirely. This means while waiting for Groq LLM completions or disk I/O, the backend would stall and become completely unresponsive to other concurrent incoming HTTP connections, severely reducing throughput.

📊 Impact:
Unblocks the main application thread completely during long-running operations. Concurrency throughput will dramatically increase when multiple users interact simultaneously, allowing the backend to scale properly under load without dropping or delaying concurrent requests.

🔬 Measurement:
I added two backend test scripts to measure ticks of an asynchronous concurrent heartbeat task while a blocking operation occurred:

  • backend/tests/verify_blocking.py: Measured 0 async ticks (completely blocked) when using direct synchronous blocking vs 20 async ticks (unblocked) when offloading to asyncio.to_thread().
  • Standard backend unit tests pass reliably over the newly refactored endpoints.

PR created automatically by Jules for task 17820755677010460084 started by @Deepaksingh7238

Switched from synchronous Groq client to `AsyncGroq` and wrapped all
synchronous SQLite persistence calls in `asyncio.to_thread`. This resolves
severe concurrency bottlenecks by ensuring the FastAPI main event loop is never
blocked by external I/O operations.

Co-authored-by: Deepaksingh7238 <110552872+Deepaksingh7238@users.noreply.github.com>
Copilot AI review requested due to automatic review settings April 30, 2026 15:52
@google-labs-jules
Copy link
Copy Markdown
Contributor

👋 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 @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.


For security, I will only act on instructions from the user who triggered this task.

Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR aims to improve FastAPI concurrency by eliminating event-loop blocking work in async endpoints, primarily by switching Groq calls to the async client and offloading synchronous SQLite persistence operations to a thread pool.

Changes:

  • Switched Groq usage in backend/main.py from Groq to AsyncGroq and awaited LLM generation calls in /ai-voice and /initiate-transfer.
  • Offloaded synchronous SQLite persistence calls (create_transfer_record, set_agent_b, list_transfers, get_transfer) using await asyncio.to_thread(...).
  • Added two local verification scripts under backend/tests/ plus a short engineering journal entry in .jules/bolt.md.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File Description
backend/main.py Uses AsyncGroq with await and offloads synchronous persistence work via asyncio.to_thread to reduce event-loop blocking.
backend/tests/verify_groq_blocking.py Adds a script intended to demonstrate sync Groq blocking behavior.
backend/tests/verify_blocking.py Adds a script to demonstrate generic blocking vs asyncio.to_thread offloading behavior.
.jules/bolt.md Adds a short note documenting the “Bolt” learning/action about avoiding blocking calls in async endpoints.
Comments suppressed due to low confidence (1)

backend/main.py:496

  • Using asyncio.to_thread(...) requires Python 3.9+, and this file also uses PEP 604 union types (str | None) which require Python 3.10+. The README currently documents Python 3.8+; please update the documented runtime requirement (or provide a 3.8-compatible fallback such as loop.run_in_executor).
            # ⚡ Bolt: Offload synchronous DB operations to thread pool
            rec_id = await asyncio.to_thread(
                persistence.create_transfer_record,
                room_name=request.room_name or "unknown",
                agent_a=request.agent_a_identity or "unknown",
                summary=summary,
                call_context=request.call_context
            )

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +3 to +11
from groq import Groq

def test_blocking():
client = Groq(api_key="sk-test", max_retries=0)
try:
client.chat.completions.create(
messages=[{"role": "user", "content": "hi"}],
model="llama3-8b-8192"
)
ticks = await task
print(f"Ticks with sync blocking: {ticks}")

asyncio.run(main())
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants