Closing connections with RabbitMQ leads to warnings in the broker side

[stronk7]

Describe the bug
While advancing with some application using faststream, by coincidence I went to look to RabbitMQ logs and found lots of warnings about unexpected closed connections.

After debugging a lot locally, initially expecting that it was some bug my side, I think that I'm doing things properly (start & close). And have reduced the problem to a minimal example.

Note I'm a noob and maybe I'm missing something, but haven't been able to find anything in docs, issues, discussions about how to, properly, stop/close a connection. Also note that this problem, apparently, doesn't cause any trouble and everything seems to be working ok, just it's annoying to get all those warnings in RabbitMQ logs.

How to reproduce

import asyncio

from faststream.rabbit import RabbitBroker

# Usage example
async def main():

    broker = RabbitBroker("amqp://user:pass@localhost:5672")

    await broker.start()
    await asyncio.sleep(3)
    await broker.close()

if __name__ == "__main__":
    asyncio.run(main())

And/Or steps to reproduce the behavior:

1. Run the script.

Expected behavior
Broker disconnects properly and no problems are logged in the Rabbit side.

Observed behavior
In Rabbit logs, the execution of the script leads to these logs:

2024-12-15 19:17:05.933765+00:00 [info] <0.10969.0> accepting AMQP connection 172.17.0.1:65170 -> 172.17.0.3:5672
2024-12-15 19:17:05.942399+00:00 [info] <0.10969.0> connection 172.17.0.1:65170 -> 172.17.0.3:5672: user 'user' authenticated and granted access to vhost '/'
2024-12-15 19:17:08.979577+00:00 [warning] <0.10969.0> closing AMQP connection <0.10969.0> (172.17.0.1:65170 -> 172.17.0.3:5672, vhost: '/', user: 'user', duration: '3s'):
2024-12-15 19:17:08.979577+00:00 [warning] <0.10969.0> client unexpectedly closed TCP connection

Screenshots
N/A

Environment

$ faststream -v
Running FastStream 0.5.33 with CPython 3.12.7 on Darwin

Additional context
RabbitMQ running locally, docker.

[stronk7]

In the other side, using a "sister" aio-pika (9.5.3) implementation, it seems to work.

import asyncio

import aio_pika
from yarl import URL


# Usage example
async def main():

    broker = aio_pika.connection.Connection(URL("amqp://user:pass@localhost:5672"))

    await broker.connect()
    await asyncio.sleep(3)
    await broker.close()

if __name__ == "__main__":
    asyncio.run(main())

And logs look ok:

2024-12-15 22:28:31.864364+00:00 [info] <0.11776.0> accepting AMQP connection 172.17.0.1:58520 -> 172.17.0.3:5672
2024-12-15 22:28:31.868350+00:00 [info] <0.11776.0> connection 172.17.0.1:58520 -> 172.17.0.3:5672: user 'user' authenticated and granted access to vhost '/'
2024-12-15 22:28:34.870976+00:00 [info] <0.11776.0> closing AMQP connection (172.17.0.1:58520 -> 172.17.0.3:5672, vhost: '/', user: 'user', duration: '3s')

^^^ Also, I've tried with aio_pika.connect_robust() all ok too.

[Lancetnik]

Sorry, but I can't reproduce the problem on my side - your example works as expected with our docker-compose 🤔

import asyncio

from faststream.rabbit import RabbitBroker

async def main() -> None:
    broker = RabbitBroker()

    await broker.start()
    await asyncio.sleep(3.0)
    await broker.close()

if __name__ == "__main__":
    asyncio.run(main())

2024-12-16 07:35:34.316158+00:00 [info] <0.712.0> accepting AMQP connection <0.712.0> (192.168.65.1:30176 -> 172.19.0.5:5672)
2024-12-16 07:35:34.322551+00:00 [info] <0.712.0> connection <0.712.0> (192.168.65.1:30176 -> 172.19.0.5:5672): user 'guest' authenticated and granted access to vhost '/'
2024-12-16 07:35:37.338315+00:00 [info] <0.712.0> closing AMQP connection <0.712.0> (192.168.65.1:30176 -> 172.19.0.5:5672, vhost: '/', user: 'guest')

Seems like it is an environment problem and we should take more time to dig into

Thank your for the Issue and for checking aio-pika case!