Re-using existing event loop in BlockingPortal / compatibility with pytest-asyncio

[tuukkamustonen]

Is it possible to pass existing event-loop to BlockingPortal?

Starlette/FastAPI TestClient uses blocking portal underneath, and as I've understood it spawns a thread and runs an event loop of its own there.

So if you use something like pytest-asyncio which creates the event loop, initialize an async resource in an async test or fixture, then pass that it the app, it gets run in a different event loop and might raise and error.

As an example, psycopg doesn't raise error, but asyncpg does. See sqlalchemy/sqlalchemy#12211 (reply in thread). In general, switching the event loop is probably not a good idea / guaranteed to work, if the resource maintains state like connections etc.

So... is it possible to use BlockingPortal with existing (asyncio) event loop (or should I overwrite the TestClient to use something like loop.run_until_complete() instead)?

[agronholm]

No, it's not possible to pass an existing event loop to it. When you create and enter a BlockingPortal, it uses whatever event loop was currently active. That was the whole point: to provide other threads access to that event loop. But I have some doubts about what you're doing. Why does it matter if TestClient uses a BlockingPortal under the hood? That's just their implementation detail.

[tuukkamustonen]

That implementation detail forces it to create a new loop, while I'd like to use the existing one.

If TestClient used asyncio.get_running_loop().run_until_complete(...) then that wouldn't spawn a new loop (but of course that wouldn't work if no was already running).

The specific issue is sqlalchemy/sqlalchemy#12211 (reply in thread) where running the tests and the app in different loops leads to the error with asyncpg (and might with other stuff, too, though I didn't yet experience that).