Channel closing with no error after publishing a too large message.

[ramhr]

Hello!

When producing a message larger than the max_message_size configured on the server, the operation doesn't immediately raise an error, which I guess is expected.

Instead, eventually we asynchronously get a "close channel" frame from the server, and set the @last_channel_error here:

bunny/lib/bunny/channel.rb

Lines 1989 to 1999 in fba2bc8

	when AMQ::Protocol::Channel::Close then
	closed!
	@connection.send_frame(AMQ::Protocol::Channel::CloseOk.encode(@id))
	# basic.ack, basic.reject, basic.nack. MK.
	if channel_level_exception_after_operation_that_has_no_response?(method)
	@on_error.call(self, method) if @on_error
	else
	@last_channel_error = instantiate_channel_level_exception(method)
	@continuations.push(method)
	end

The error looks like PRECONDITION_FAILED - message size X is larger than configured max size Y, and it will only be thrown the next time I try to produce from the channel as part of the message of the ChannelAlreadyClosed error.

I would like to handle the PreconditionFailed when it arrives instead of relying on a future action to get the ChannelAlreadyClosed to deduce what happened, and reopen/replace it.

To reproduce:

1. Configure your local rabbitmq.conf with max_message_size = 10
2. Open a connection and get a channel.
3. Produce a message larger message.
4. Sleep a second to wait for the AMQ::Protocol::Channel::Close frame.
5. Try to produce a message again, regardless of size.
6. Get an error: cannot use a closed channel! Channel id: 2, closed due to a server-reported channel error: PRECONDITION_FAILED - message size 17 is larger than configured max size 10

session = Bunny.new "amqp://guest:guest@localhost:5672"
session.start
channel = session.create_channel

# This fails to publish but no error is raised:
channel.default_exchange.publish("some long message", { routing_key: "my_existing_queue" })
sleep 1
begin
  # The error is instead raised here:
  channel.default_exchange.publish("x", { routing_key: "my_existing_queue" })
rescue Bunny::ChannelAlreadyClosed => e
  puts e
  # #<Bunny::ChannelAlreadyClosed: cannot use a closed channel! Channel id: 1, closed due to a server-reported channel error: PRECONDITION_FAILED - message size 17 is larger than configured max size 10>
end

channel.open
# This message is successfully published: 
channel.default_exchange.publish("x", { routing_key: "my_existing_queue" })

I can check if channel.closed? before every publish and reopen or replace it as needed, but I won't be able to inspect the error if I do that as it's private, so maybe just producing regardless and catching the ChannelAlreadyClosed is better as a compromise. Or maybe adding the specific message to the channel_level_exception_after_operation_that_has_no_response? like on #682 is the correct approach.

Or is there a way to get the configured max_message_size from the server to add validation on the message before producing, and avoid the issue altogether?

I'm wondering what's the best approach to handle it, and I'd love for advice 🙂

[michaelklishin]

Error notifications for channel operations (including publishing) is asynchronous in the protocol.

See Bunny::Channel#on_error(&block) and Bunny::Channel#on_uncaught_exception(&block), although the latter only applies to consumers IIRC.

[ramhr]

Thank you for the response @michaelklishin.

I tried that, but the @on_error is only ever called if channel_level_exception_after_operation_that_has_no_response?, so only for errors with a message matching /unknown delivery tag/ or /delivery acknowledgement on channel \d+ timed out/.

bunny/lib/bunny/channel.rb

Lines 2009 to 2011 in fba2bc8

	def channel_level_exception_after_operation_that_has_no_response?(method)
	method.reply_code == 406 && (method.reply_text =~ /unknown delivery tag/ || method.reply_text =~ /delivery acknowledgement on channel \d+ timed out/)
	end

The regex for the error I'm trying to handle would be message size \d+ is larger than configured max size \d+. Should I make a PR to add it to the condition like on #682?

[michaelklishin]

@ramhr it should not be a standard condition you'd need to handle. That said, I have no problem with adding /larger than configured max size/ to the list.