¿Cómo tratarías una llamada bloqueante a una librería dentro de un endpoint asíncrono de FastAPI?

Sácala del event loop. Envuelve la llamada bloqueante en asyncio.to_thread, o usa run_in_executor con un thread pool, para que el loop quede libre para atender otras peticiones. Si el trabajo tiene carga de CPU, mándalo a un process pool o a un worker en segundo plano como Celery. Si lo dejas en línea, una sola llamada lenta atasca todas las demás peticiones de ese worker.

La razón por la que importa es que asyncio es cooperativo y de un solo hilo, así que una corrutina se queda el loop hasta que hace await de algo. Una llamada bloqueante a un driver metida en un handler asíncrono congela todas las demás peticiones en vuelo de ese worker, y con poco tráfico no te vas a enterar nunca. El arreglo más barato en FastAPI es definir el endpoint con def normal en vez de async def, y el framework lo ejecuta en su threadpool por ti. Si lo necesito dentro de una función asíncrona, asyncio.to_thread envuelve la llamada y espera el resultado. Donde tengo cuidado es en el tamaño del thread pool, porque el valor por defecto es pequeño y una dependencia lenta te va a hacer cola detrás, así que lo dimensiono según la concurrencia que espero y añado un timeout. Para cualquier cosa pesada de CPU, los hilos no ayudan con el build por defecto, así que va a un process pool o fuera, a un worker de Celery. Cazamos una de estas con un cliente SOAP antiguo que tardaba ocho segundos, y la latencia p99 de un servicio entero iba siguiendo esa única llamada.