Exceeding max number of consumers per channel crashes connection

[markus812498]

Describe the bug

Version: 3.13.1
Erlang: 26.2.1 [jit]

When setting a value for consumer_max_per_channel and exceeding this value, the connection throws an error and terminates. Attached is the log snippet with the crash.

log_snippet.txt

Reproduction steps

1. Run 3.13.1
2. Set consumer_max_per_channel to 10 (I used sbin/rabbitmqctl eval 'application:set_env(rabbit,consumer_max_per_channel, 10).')
3. use any client to create a channel, and create 11 consumers on that channel ( I used bunny).
4. Connection errors and crash.

Expected behavior

I would expect that the channel to block new consumers, but that the connection and the channel remains open.

Additional context

Relevant commit: 49e119d
looks like the MaxConsumers is assigned "\n"? If I replace MaxConsumers with an arbitrary atom in https://github.com/rabbitmq/rabbitmq-server/blob/main/deps/rabbit/src/rabbit_channel.erl#L1326 then it's not crashing (but connection still closing which might be expected?).

[markus812498]

Missed that the original PR (#10749) stated:

Note that crossing the limit crashes the connection. Same behavior as channel limit, so I figured it's acceptable.

so my expected behaviour is wrong, it's expected that the connection should terminate.

[michaelklishin]

Consumers are scoped per channel, not per connection. Returning a sensible error from a channel is easy, doing the same from connection is also possible but we don't have too many examples of where this is done outside of the connection negotiation sequence.

It's a guardrail to protect RabbitMQ from applications leaking consumers, so I don't know how much anyone really cares about returning a meaningful error to a leaking application (logging an informative message is a different story, of course).

If someone does, they are welcome to look into it and contribute an improvement. See connection.tune handles in rabbit_reader for examples of how connections can be closed with an error propagated to the client.

[markus812498]

cool. Yeah it's on me for not reading the expectations from the original PR, and we're happy with the current implementation although my expectations were incorrect. I can raise a PR to fix the logging errors.

Thanks!