TempCluster() and pytest

[takeda]

• asyncpg version: 0.23.0
• PostgreSQL version: N/A
• Do you use a PostgreSQL SaaS? If so, which? Can you reproduce the issue with a local PostgreSQL install?: N/A
• Python version: 3.8.9 (but N/A)
• Platform: N/A
• Do you use pgbouncer?: N/A
• Did you install asyncpg with pip?: yes
• If you built asyncpg locally, which version of Cython did you use?:
• Can the issue be reproduced under both asyncio and uvloop?:

This is issue which happens when using TempCluster() for testing as mentioned in https://github.com/MagicStack/asyncpg/issues/589.

Basically invoking cluster.start() causes an error when trying to use in environment that sets up own event loop (like pytest). Because .start() calls self._test_connection(timeout=wait) which creates and uses own event loop (https://github.com/MagicStack/asyncpg/blob/d08a9b8b9c2c68d469aeb9c4112d83c56c24f11c/asyncpg/cluster.py#L467).

This can be worked around by using nest_asyncio package, but it would be great if we could pass the event loop to the start() method so no hacking around that would be needed.

[elprans]

Oh, cluster.py is private to asyncpg, ideally you shouldn't rely on it directly as an API. That said, a better fix here would likely be to run _test_connection in a separate thread to avoid clashing with a running loop, if any.

[takeda]

I similarly wanted to mock asyncio, and followed recommendation in https://github.com/MagicStack/asyncpg/issues/589. And actually perhaps that's more reliable test as it also can somewhat test correctness of my SQL.

I also tried to run cluster.start(port="dynamic") as a thread, but it just changed message from: RuntimeError: Cannot run the event loop while another loop is running

to: RuntimeError: This event loop is already running

Although after investigating it more I think it actually might be similar problem but this time in TestClient in FastAPI and the nest_asyncio was hiding it, so I think it solves the problem.

But since the crux of my issue is that I'm already in an event loop when running the cluster, I'm wondering if maybe less hacky solution would be actually detecting that and maybe return a future with when connection is ready, or having an alternative start() method that's async?