GeezerVison

Apparently there is some weird behavior in python that does not work the way that other languages do.

This will cause issues for the async client (but not the sync client):

import asyncio
from runloop_api_client import AsyncRunloop
async def run_once():
    client = AsyncRunloop(bearer_token="token")
    await client.devboxes.retrieve("devbox-id")
    # imagine this client is not closed, or cleanup does not fully await close
asyncio.run(run_once())  # creates/uses shared async pool on loop A
asyncio.run(run_once())  # reuses same global AsyncClient on loop B

asyncio.run() creates a fresh event loop each time and closes it when done. On the second call, the global _shared_async_client may still point at the client first used on loop A. When loop B tries to use it, failures can show up as runtime errors like “event loop is closed”, “bound to a different event loop”, “attached to a different loop”, hanging cleanup, or flaky transport errors depending on exactly what state httpx/anyio has cached.

Python wants you to scope-manage the async pool instead of having one consolidated async pool. I find this extremely counterintuitive but it sorta makes sense given how the async client binds to the transport layer:

The reason that can break is that an httpx.AsyncClient internally uses async primitives and transports from httpcore/anyio. After it has opened connections, those internals can be tied to the async backend/loop that created or used them. If you later drive the same client from a different loop, Python may complain because loop-owned objects are being awaited or closed from the wrong loop.

The suggestion is to add an extra bit of loop awareness so that requests don't accidentally tread on each other. Something a bit like:

_async_pools: weakref.WeakKeyDictionary[asyncio.AbstractEventLoop, PoolState]

loop = asyncio.get_running_loop()
pool = _async_pools.get(loop)
if pool is None or pool.client.is_closed:
    pool = PoolState(client=AsyncHttpxClientWrapper(...), refcount=0)
    _async_pools[loop] = pool

The garbage collector should mop up resources, but this does also imply a need to change the close to ensure aclose and close play together nicely. So, the suggested changes:

• async client: shared pool keyed by current event loop, created lazily on first request
• explicit async close awaits final aclose()
• add tests that create/use clients across two separate asyncio.run(...) calls

This looks good to me. One potential edge case for user-supplied http clients in comments.

I also saw this changed:
DEFAULT_CONNECTION_LIMITS = httpx.Limits(max_connections=20, max_keepalive_connections=10)

I think this is intentional, but since it was 100 previously I just want to call it out in case it was a temporary change.