time.sleep() inside async lifespan — intentional or worth switching to await asyncio.sleep()?

[Joaquinriosheredia]

Hi,

While analyzing the codebase with python-vibe-guard, I noticed that
the FastAPI lifespan function in core/fastapi_app.py uses
time.sleep(retry_delay) inside an async def:

async def lifespan(app):
    for attempt in range(max_retries):
        try:
            await init_db()
            break
        except Exception:
            time.sleep(retry_delay)

time.sleep() blocks the entire event loop during startup retries.
The impact is likely small since traffic is minimal during startup,
but if health-check or readiness probes share the same event loop
from the first instant, they could be delayed during DB reconnection attempts.

Was this intentional, or would await asyncio.sleep(retry_delay)
be a welcome one-line improvement?

Tool used: python-vibe-guard —
AST-based runtime anti-pattern scanner validated on 902 real repositories.

[Jovonni]

Good catch — you're right, that backoff blocks the event loop. Switched it to await asyncio.sleep() and added a small regression test around the lifespan retry path. Fix is up in #142.

[Joaquinriosheredia]

Thanks for the quick fix and for adding the regression test —
that's exactly the right approach. Really appreciated!

[Jovonni]

No problem! thanks for reporting this 🫡

We are going to do some additional testing just for sanity

🚀