Can't use Shovel with Quorum queues.

[lpiob]

Describe the bug

When a RabbitMQ is initialized with definitions containing both quorum queues and shovels targeting those queues, the queues are created as classic ones.

This was reported before in #3782.

I believe that the error is in the order RabbitMQ processes new definitions, as the simplest way to reproduce the issue is to export correct definitions and import them to a (blank) cluster.

There is no way to seed a blank cluster with correct parameters without separate process for queue definitions and shovel definitions. The export/import functionality is unreliable.

Manually reordering parameters after the queues in definition file has no effect.

Reproduction steps

1. Create two quorum queues
2. Create a shovel reading from first quorum queue and writing to second quorum queue
3. Export definitions, recreate the cluster, import the defintions
4. Observe that the target queue is classic, not quorum

Expected behavior

• Shovel definitions should not override queue types.
• Import/export definitions functionality should not break queue types.

Additional context

No response

[lpiob]

We were able to establish that the problem can be circumvented by manually editing shovels definitions to include the src-queue-args and dest-queue-args parameters, for example:

"parameters": [
    {
      "value": {
        ...
        "dest-protocol": "amqp091",
        "dest-queue": "TargetQueue",
        "src-queue": "SourceQueue",
        "dest-queue-args": {
          "x-queue-type": "quorum"
        },
        "src-queue-args": {
          "x-queue-type": "quorum"
        }
      },
]

This will make exported definitions correct and new queues will be created correctly as quorum and not classic types.

This is only a workaround, the original bug persists, as these definitions will not automatically appear for quorum queues, nor is it possible to enter them from the management interface.
and the exported definitions will be co

[michaelklishin]

Please use Discussions for questions.

That would be one option. Another would be to set the default queue type of the virtual host(s) in question to quorum.

[lpiob]

There was no question posed here.

The fact that a workaround (or two) exists, does not mean the bug does not exist. I believe that the bugreport was correct.

[michaelklishin]

If something surprises you, it is not necessarily a bug. Everything in your description works as expected. Before you claim that something is a bug, ask yourself how well you understand what is going on and why.

A Shovel are just a special kind of client that runs on a RabbitMQ node. As any other client, a Shovel must specify a matching set of queue properties a declaration time. That's how
the protocol works.

There are several options available:

1. What you have discovered: specify additional queue arguments
2. What I have suggested: set the default queue type for the virtual host(s) in question so that all queues declared without an explicit type will be quorum ones
3. Shovels could "probe" if a queue exists and avoid declaring a queue if it does. In theory it sounds like a usability improvement. Whether it'd be an actual improvement in practice, I don't know. This would be a subtle behavior change and these tend to really anger a very small but very vocal number of people

[michaelklishin]

Option 3 was implemented in #11823 for RabbitMQ 4.0.

[michaelklishin]

Here is a specific improvement that may help this case #10501. Like the issue says, it may also produce subtle side effects, so this is not a promise of delivery of any kind.