Synchronous yfinance calls block the async event loop in market data endpoints

[aadityat23]

Problem

backend/app/market.py's _get_ticker_fast (and the equivalent info-fetching function) call yfinance's synchronous, network-blocking API directly. These functions are plain def, not async def, and are invoked directly — without asyncio.to_thread or run_in_executor — from async def route handlers in main.py such as /market/quotes and /market/indices.

Why this matters

FastAPI's async event loop is single-threaded for coroutine execution. A blocking network call inside an async def handler stalls the entire event loop for every other concurrent request — not just the one making the yfinance call — until that call returns or times out. Under real traffic (multiple users hitting the market/watchlist pages, or the periodic WebSocket refresh), this turns an occasional slow yfinance response into a global slowdown for the whole API, including unrelated /verify and /v1/fcg/verify requests.

Acceptance Criteria

• All synchronous yfinance calls in market.py are offloaded via asyncio.to_thread (or an equivalent bounded executor pattern) when called from async route handlers

• Offloaded provider calls use bounded concurrency (e.g. asyncio.Semaphore or an equivalent mechanism) to prevent unbounded parallel yfinance requests under load

• A route/service-level timeout is enforced around the offloaded provider call so slow or hung upstream requests cannot indefinitely occupy worker resources

• No change to the existing cache/rate-limit semantics (10-second TTL, stale-fallback behavior)

• Blocking provider functions remain synchronous, while async callers use a dedicated async wrapper/adapter that owns the offload, timeout, and concurrency control

• A test or benchmark demonstrates that a slow/blocked yfinance call no longer prevents a concurrent /health or /verify request from completing promptly

• Tests added where appropriate

• Documentation updated if necessary — a short comment explaining why the async offload exists, so it isn't accidentally reverted

• (Optional) Metrics/logging distinguish cache hits, stale-cache hits, provider successes, provider timeouts, and provider errors

Files likely to modify

finverify-terminal/backend/app/market.py
finverify-terminal/backend/app/main.py

Skills required

Python, asyncio, FastAPI, concurrency concepts

Estimated difficulty

3/5

Estimated effort

4–6 hours

[initial-d]

This is a good issue to keep separate from the shared-cache/rate-limit work. Offloading the blocking yfinance calls fixes event-loop starvation, but it should not accidentally turn into unbounded parallel Yahoo traffic.

A few acceptance details I would add:

• use a bounded executor or an asyncio.Semaphore, not raw unlimited to_thread calls; otherwise concurrent requests can create a thundering herd of yfinance calls
• preserve the stale-cache fallback path around the offloaded call, so a slow provider does not make the endpoint slower than the current cache behavior
• put a timeout around the thread future at the route/service boundary, even if yfinance itself also has request timeouts
• add a regression test with one endpoint whose market-data call is artificially blocked and one unrelated lightweight endpoint; the lightweight endpoint should still complete quickly
• track the difference between cache hit, stale hit, provider success, provider timeout, and provider error in logs/metrics

One small design preference: keep the synchronous yfinance wrapper as a plain function, then expose an async adapter such as await get_ticker_fast_async(...) that owns semaphore + timeout + to_thread. That makes it harder for future route handlers to accidentally call the blocking version directly.

[aadityat23]

Thanks for the detailed review @initial-d ! I've updated the acceptance criteria to incorporate the key implementation recommendations:

• bounded concurrency (asyncio.Semaphore or equivalent)

• route-level timeout around the offloaded provider call

-preserving existing cache/stale-fallback behavior

• a regression test proving unrelated endpoints remain responsive

• an async wrapper/adapter to centralize the offload logic

• a short code comment explaining why the offload exists

I left the metrics/logging suggestion as a follow-up enhancement rather than a merge requirement to keep this issue focused on fixing event-loop starvation. Thanks again for the detailed feedback!