eandersson / amqpstorm

Thread-safe Python RabbitMQ Client & Management library
https://www.amqpstorm.io/
MIT License
186 stars 36 forks source link

Channel error handling on passive queue declaration #114

Closed bhoehl closed 2 years ago

bhoehl commented 2 years ago

When declaring a queue, which is not yet declared, using passive=True, an error is raised and the channel ought to be closed. The code behaves as if so, but continuing using channels is causing an error on the server:

What can also be observed, is that the RabbitMQ server ( 3.7.8) is listing the channel after this error as open in the admin web UI. The error can easily be reproduced by establishing a RabbitMQ connection and using this code snippet:

try:
    channel = conn.channel()
    channel.queue.declare('test', passive=True)
except Exception as e:
    print(str(e))
    # Channel 1 was closed by remote server: NOT_FOUND - no queue 'test' in vhost '/'
    # this is not true, as the channel is still listed in the web user interface ( 15672 )

# Further calls to get a new or other channel also fail, because the channel id is reused
channel = conn.channel()
# is causing an error on the server
# operation channel.open caused a connection exception channel_error: "second 'channel.open' seen"
# because it is still open
# the program hangs at this point and does not return from conn.channel()

There is no chance of handling this, except closing the whole connection. I would consider this a bug. Please check, if you can reproduce. Btw. it does not matter if you add channel.close() or use with in between. Even the latest RabbitMQ version 3.9.9 behaves the same.

eandersson commented 2 years ago

Thanks for the report. There is definitely something wrong here.

eandersson commented 2 years ago

Figured it out. I'll get a patch out this weekend. The issue is that we do not send a CloseOk back when the channel is forcefully closed, so the second channel is still waiting for that message, causing it to get into a weird state.