Completing Requests After AsyncClient.aclose()

[aaronst]

If there are pending requests for an AsyncClient because we hit the max_connections limit, and then we call AsyncClient.aclose(), are those pending requests cancelled? Or will they still get their chance to run? If they're cancelled, does the AsyncClient provide any information that would help us determine if there are any pending requests before calling AsyncClient.aclose()?

[tomchristie]

If you close a client while it still has requests/responses in flight, it'll raise a RuntimeError indicating that you've closed the client incorrectly.

To properly perform an early close you'd need to cancel any not-yet-complete tasks before closing the client.

You shouldn't run into this as an issue unless you've got a bit of an oddly structured (broken) code.

---

A bit of additional context here in case you're interested...

Python's asyncio doesn't (yet) protect developers much here because of the way it allows tasks to be created, and then forgotten about.

TaskGroups are coming to Python with 3.11, which will be a much improved API for managing task concurrency.

In the meantime anyio is a great option for helping you develop properly structured async code... https://anyio.readthedocs.io/en/stable/tasks.html

There's also the Trio package is a fantastically designed alternative to asyncio.

Further reading: https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/

[aaronst]

This is great info, thanks. When you say in flight, does that include requests which haven't actually been sent yet because they're waiting on a connection from the pool?

[tomchristie]

Yup.

[jeremyschulman]

@tomchristie - I agree with what you are suggesting. In my case I have requests that have been sent, but not yet received (in-flight) Per my other issue in httpcore 510, what do you think about raise an httpcore.exception (raise httpcore.PoolInUse, for example?) vs a RuntimeError so we can trap and differentiate it from others?

[aaronst]

Would it make sense for AsyncClient.aclose() to block until all in-flight requests have completed?

[jeremyschulman]

@aaronst - so as a workaround, I am doing this. I create a list of httpx.AsyncClient instance first, run some requests, and then close the list.

 await asyncio.gather(*{dev.aclose() for dev in devices}, return_exceptions=True)

But in doing this approach, I cannot use httpx.AsyncClient in a context manager form, such as:

    async with Device(host=hostname) as dev:
        # if the MAC address is not on this device, then return None.
        if not (interface := await dev.find_macaddr(macaddr)):
            return None
    
        # if the MAC address is found, but not on an edge-port, then return
        # None.
        if not await dev.is_edge_port(interface=interface):
            return None

    # -close client