Stage 8 · L33

Choose sync or async by the actual library boundary

Core · original Session 8

async def is useful when a handler awaits compatible nonblocking I/O. It is not a general speed switch. A synchronous SQLAlchemy call still blocks its executing thread; putting it directly in an async handler can block the event loop. This core stage follows the original Session08 pattern: synchronous owned preparation, then async outbound HTTP.

prepare_lookup is a synchronous dependency and FastAPI runs it in the worker-thread facility. It resolves the allowed stored rental and returns a frozen Reference. The async route then awaits Gateway.lookup. The database session is already closed; no SQLAlchemy row or relationship crosses that await boundary.

The application lifespan owns one AsyncClient so connections can be reused and closed intentionally. Creating a client for every attempt discards pooling and makes ownership harder to review. A per-request session is not an appropriate place to keep an application HTTP client. The fixture verifies client.is_closed after lifespan exit.

Admission uses an asyncio.Semaphore to bound concurrent lookups in this one application event loop. It is not a global limit across multiple Uvicorn workers or hosts. The total lookup timeout includes time waiting for this local slot, HTTP attempts and retry sleeps. A local pool/admission shortage is classified separately from a provider outage.

An optional later extension demonstrates real async database sessions using psycopg's async dialect. That is additional implementation, not a claim that the original provider source requires async PostgreSQL. Choose a coherent resource model and test it; do not mix blocking calls into an event loop because a diagram contains await.

import asyncio
async def wait(label):
    await asyncio.sleep(0.02)
    return label
async def main():
    assert await asyncio.gather(wait('A'), wait('B')) == ['A', 'B']
asyncio.run(main())

await asyncio.sleep yields the event loop; a blocking call still blocks its executing thread. gather returns results in input order and can overlap independent waits, but keep concurrency bounded and preserve dependencies. The core keeps synchronous SQL preparation; this exercise contains no HTTP retry, payload policy or circuit breaker.