Open maciejharczuk opened 1 year ago
Hello, what version of RabbitMQ and Erlang are you using?
Streams are definitely not supported at this time, FYI.
(@michaelklishin please don't convert this to a discussion. There are legitimate things to work on for the second item, and I'm investigating the first).
I was able to reproduce it with rabbitmq:3.11.16-management-alpine docker image, which means it's RabbitMQ 3.11.16 & Erlang 25.3.2.
Interestingly, a shovel gets created and declares a stream if I remove the 'x-max-age' but leave "x-queue-type": "stream", so it kind of works, although more by accident than by design if I understood the code correctly.
It looks like in the first case that the json isn't getting correctly converted into an AMQP table. That feature was introduced in this PR.
Thanks again @G-r-F, we'll look into this as time allows.
Streams are definitely not supported at this time, FYI.
Why would that be? I don't see it documented as not being supported. There is functionality especially dedicated to this: https://github.com/rabbitmq/rabbitmq-server/commit/de8dd5fb69b1f03f5011143a11edd5c1308c0363
@johanrhodin because we haven't done any meaningful amount of work to support streams. Shovels don't have to use AMQP 0-9-1 for streams, for example.
Describe the bug
I have identified two cases where shovel creation request to management api fail because dest-queue-args are not handled correctly, resulting in HTTP 500 and a stack trace being logged.
Reproduction steps
Case 1: Creating a shovel for a quorum queue, trying to specify DLX and DLX routing key for the destination queue that we want the shovel to create
curl -XPUT http://localhost:15672/api/parameters/shovel/vhost1/stream-test -u guest:guest -d "@./shovel_payload.json" -v
with the following payloadResults in a following stack trace:
Case 2: Creating a shovel for a stream, trying to specify x-max-age for the destination stream.
curl -XPUT http://localhost:15672/api/parameters/shovel/vhost1/stream-test -u guest:guest -d "@./shovel_payload.json" -v
JSON payload:Expected behavior
I would expect the dest-queue-args to be used when the shovel declares a destination queue. Alternatively, if those particular args can not be supported for whatever reasons, it should be caught during parameter validation and HTTP 400 with meaningful error message should be returned instead of a 500 with no useful info.
Additional context
No response