Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Channel error handling on passive queue declaration #114

Closed
bhoehl opened this issue Nov 19, 2021 · 2 comments
Closed

Channel error handling on passive queue declaration #114

bhoehl opened this issue Nov 19, 2021 · 2 comments
Labels
Milestone

Comments

@bhoehl
Copy link
Contributor

bhoehl commented Nov 19, 2021

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:

  • operation channel.open caused a connection exception channel_error: "second 'channel.open' seen"

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 eandersson added the bug label Nov 19, 2021
@eandersson
Copy link
Owner

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

@eandersson
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants