@ASYNC_TEST
async def test_publish_after_disconnect(connection):
    await connection.close()
    with pytest.raises(carehare.ConnectionClosed):
        await connection.publish(b"foo", routing_key="messages")

Expected results: raise carehare.ConnectionClosed
Actual results: stall

Looks like carahare can only publish transient messages - all of which will be gone after rabbitmq cluster restarts (even though with lazy queues they'll be persisted to disk).

Is that an intended way?

I expect that await connection.publish(message, routing_key) completes only when the consumer sends the ack, but it completes right after the message is sent to the queue.

Is there a way to meet my expectations? Or maybe it is a bug?

I need AMQP header access for received messages.
Looks like overriding next_delivery() (either by subclassing or plain old monkey-patching) should do the trick, but it would be nice to have next_delivery_with_headers() available out of the box (with a better name, probably..). Do you accept PRs? What would you suggest for a function name?

Also, ability to set queue arguments would be nice - x-stream-offset argument in particular, to use with rabbitmq streams.

PS: That asyncio.wait() trick in _next_delivery() is really awesome! I was really wary of asyncio.wait_for() for as long as I can remember, but couldn't find a decent solution.

Accoring RabbitMQ specificatiosn vhost segment does not include leading slash:

amqp_URI = "amqp://" amqp_authority [ "/" vhost ] [ "?" query ]
The vhost component of the URI does not include the leading "/" character from the path. This makes it possible to refer to any vhost, not only those that begin with a "/" character.

But carehare uses an 'urlparse' python function (https://github.com/CJWorkbench/carehare/blob/main/carehare/_connection.py#L35 and https://github.com/CJWorkbench/carehare/blob/main/carehare/_connection.py#L60) which does not strip leading slash.

>>> urllib.parse.urlparse(carehare.connect('amqp://guest:[email protected]/sample_vhost')._url).path
'/sample_vhost'

I'd like to suggest a change in the way Protocol.connection_lost() records the loss of a connection. At the moment, it does this:

logger.info("Connection lost: %r", exc)

even when exc is None (on a normal disconnection, IIUC). I think it would be better to not output anything if exc is None, else a higher severity should be used (warning or error), for example:

if exc:
    logger.error("Connection lost: %r", exc)