Comment traiteriez-vous un appel de bibliothèque bloquant à l'intérieur d'un endpoint FastAPI asynchrone ?

Sortez-le de la boucle d'événements. Enveloppez l'appel bloquant dans asyncio.to_thread, ou utilisez run_in_executor avec un pool de threads, pour que la boucle reste libre de servir d'autres requêtes. Si le travail est limité par le CPU, envoyez-le plutôt vers un pool de processus ou un worker de fond comme Celery. Laissé en ligne, un seul appel lent fige toutes les autres requêtes de ce worker.

Ce qui rend cela grave, c'est qu'asyncio est coopératif et monothread, donc une coroutine garde la boucle tant qu'elle n'attend pas quelque chose. Un appel de pilote bloquant posé dans un handler asynchrone gèle toutes les autres requêtes en vol sur ce worker, et sous faible trafic vous ne le remarquerez jamais. Le remède le moins cher dans FastAPI est de définir l'endpoint avec un def simple plutôt qu'un async def, et le framework l'exécute dans son pool de threads pour vous. Si j'en ai besoin dans une fonction asynchrone, asyncio.to_thread enveloppe l'appel et en attend le résultat. Là où je fais attention, c'est à la taille du pool de threads, parce que la valeur par défaut est faible et qu'une dépendance lente formera une file derrière, donc je le dimensionne selon la concurrence attendue et j'ajoute un timeout. Pour tout ce qui est lourd en CPU, les threads n'aident pas sous la build par défaut, donc cela part vers un pool de processus ou vers un worker Celery. Nous en avons attrapé un avec un vieux client SOAP qui prenait huit secondes, et la latence p99 de tout un service suivait cet unique appel.