Validate queue and consumer arguments #4572
Conversation
|
Plugins using custom x-args will continue to work after this PR because custom x-args are never validated or invalidated (assuming the custom x-arg is not part of the list of supported x-args of any existing queue type). This is because this PR uses some form of "weak" validation: I'm not sure whether it's possible to extend RabbitMQ with custom queue types at the moment. I think there are some hard-coded assumptions that only We could also enable the new validation of this PR by default, but could add a config option allowing to disable this new validation (just in case I overlooked a breaking change scenario). Alternatively, if we think this validation will cause more trouble than people find it helpful (my opinion is it will overall cause less confusion) we can also close this PR and just delete the list of supported x-args per queue type as originally done in #4404 since they are currently not used anywhere. |
|
Thanks for the explanation, @ansd. "Validate known and accept the rest" sounds like a good balance. No objections from me. |
|
This needs conflicts to be resolved, otherwise LGTM. |
Throw a PRECONDITION_FAILED error when a queue is created with an invalid argument. There can be RabbitMQ plugins and extensions out there defining arbitrary queue arguments. Therefore we only check that a queue is not declared with arguments that we know are supported only by OTHER queue types. The benefit of this change is that queues are not mistakenly declared with the wrong arguments. For example, a stream should not be declared with `x-dead-letter-exchange` because this argument is not supported in streams. It is only supported by classic and quorum queues. Instead of silently allowing this argument and users wondering why the stream does not dead letter any messages, it's better to fail early with an meaningful error message. We still allow any other arbitrary queue arguments. (Therefore and unfortunately, when `x-dead-letter-exchange` is misspelled, it will still be accepted as an argument). For argument equivalence, we only validate the arguments that are supported for a queue type. There is no benefit in validating any other arguments that are not supported anyways.
Throw a PRECONDITION_FAILED error when subscribing with an invalid consumer argument.
Delete arguments: x-dead-letter-exchange x-dead-letter-routing-key x-max-length x-single-active-consumer None of these arguments are supported in streams. Dead lettering does not apply to streams. x-max-length does not apply, only x-max-length-bytes and x-max-age apply. Single active consumer does not work on the queue level, it will only work on the consumer level. This is different to single active consumer for classic and quorum queues.
Delete x-max-in-memory-length and x-max-in-memory-bytes from classic queues since they were only supported by quorum queues. Add delivery-limit to unsupported policies of classic queues, they apply only to quorum queues.
since the RabbitMQ AMQP 1.0 plugin sets the x-credit consumer argument in https://github.com/rabbitmq/rabbitmq-server/blob/fc38cd3d98351adf0bfb060e58a33f24f0c3f331/deps/rabbitmq_amqp1_0/src/rabbit_amqp1_0_outgoing_link.erl#L66-L69 and streams support the AMQP 1.0 protocol via that plugin.
michaelklishin
force-pushed
the
validate-args
branch
from
7550c1c
to
4c04f9f
Compare
This reverts commit 457f0fb. rabbit_misc:rs/2 includes object type (e.g. queue) already
(cherry picked from commit 8ff6ed7)
|
@Mergifyio backport v3.10.x |
✅ Backports have been created
|
Validate queue and consumer arguments (backport #4572)
Follow up of #4404.
Throw a
PRECONDITION_FAILEDerror when a queue is created with aninvalid argument or when a consumer subscribes with an invalid argument.
There can be RabbitMQ plugins and extensions out there defining arbitrary
queue arguments. Therefore we only check that a queue is not declared
with arguments that we know are supported only by other queue types.
The benefit of this change is that queues are not mistakenly declared with the wrong arguments.
This change will reduce a lot of confusion when it comes to what arguments are supported by what queue type.
Example 1:
Before this PR, a stream could be created with
x-dead-letter-exchangequeue argument set. Users wonder why the stream does not dead letter any messages. After this PR, stream creation fails early with a meaningful error message because that argument is only supported for classic and quorum queues.Example 2:
Before this PR, a stream could be created with
x-max-lengthqueue argument set. Users wonder why the stream contains more messages than configured viax-max-length. After this PR, stream creation fails early with a meaningful error message because that argument is only supported for classic and quorum queues. Streams supportx-max-length-bytesandx-max-age.Example 3:
Before this PR, a quorum queue could be created with
x-queue-master-locatorqueue argument set. Users wonder why it doesn't have any effect. After this PR, queue creation will fail with a meaningful error message.All changes are backwards compatible, except invalid consumer arguments which I expect to be rare.
For example, when a consumer had consumer argument
x-priorityset to connect to a stream via AMQP, this will start failing after this PR.