You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If the channel is reopened (in the event of a channel error, such as exchange not found), _confirm_selected should be set to False again, otherwise the client will continue to wait for the ACK, but the server will not reply.
The text was updated successfully, but these errors were encountered:
I encountered this issue with amqp==5.0.9, celery==5.2.3, kombu==5.2.4.
It can be recreated with the following run.py script with the celeryconfig.py file. The script (successfully) publishes a message, then (unsuccessfully) tries to purge a non-existent queue, then publishes a second message. The publishing of the second message hangs forever.
amqp.channel.Channel.basic_publish_confirm calls self.confirm_select() when the first message is posted, enabling publisher confirms on the channel.
Purging a non-existent queue causes the channel to be closed and re-opened (amqp.channel.Channel._on_close is called at some point). The channel is re-opened without publisher confirms enabled.
apply_async/basic_publish_confirm still use the same amqp.channel.Channel object, which has self._confirm_selected = True, even though the channel itself doesn't have publisher confirms enabled.
basic_publish_confirm waits forever for a publish confirmation that will never arrive.
This can be worked around by adding a timeout argument to the hanging apply_async call. This stops the apply_async call from hanging forever, but does end up publishing the message twice. This doesn't feel like the real fix though. I think the real fix might be to reset self._confirm_selected back to False after a channel has been re-opened. I'm not super familiar with this codebase though so I might be missing something.
If the channel is reopened (in the event of a channel error, such as exchange not found), _confirm_selected should be set to False again, otherwise the client will continue to wait for the ACK, but the server will not reply.
The text was updated successfully, but these errors were encountered: