Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Management UI creates classic queue instead of virtual host default queue type in some circumstances #11088

Open
SignalWhisperer opened this issue Apr 25, 2024 · 2 comments
Labels

Comments

@SignalWhisperer
Copy link
Contributor

Describe the bug

In the management UI, when I go to create a new queue and elect to use the Default for virtual host, I am presented with the queue Durability selector. When the virtual host default queue type is quorum or stream, selecting Transient will give me a classic queue instead. Selecting Durable gives me the expected queue type.

image
image
image
image image

When selecting quorum or stream as the queue Type instead of Default for virtual host, the Durability selector disappears.

image

Reproduction steps

  1. Create a new virtual host with quorum or stream as the default queue type
  2. Go to the Queues and Streams tab
  3. Select your new virtual host in the Virtual host selector
  4. Select Default for virtual host for the queue Type selector
  5. Observe there is a Durability selector visible
  6. Give the queue a name
  7. Select Transient for the Durability selector
  8. Create the queue
  9. Observe it is created as a classic queue

Expected behavior

The Durability selector should not be shown when the default queue type for that virtual host is quorum or stream.

It should also not give me a classic queue when I select Transient but rather an error message (debatable as fixing the above expected behaviour would render the error message irrelevant).

Additional context

No response

@SignalWhisperer
Copy link
Contributor Author

Sorry, I forgot to mention this was identified on RabbitMQ 3.13.0 and repeated on 3.13.1.

@SimonUnge
Copy link
Collaborator

I would say its intentional:

    case vhost:get_metadata(V) of
        #{default_queue_type := DefaultQueueType}
          when is_binary(DefaultQueueType) andalso
               not HasQTypeArg ->
            Type = rabbit_queue_type:discover(DefaultQueueType),
            IsPermitted = is_queue_args_combination_permitted(
                            Durable, Exclusive),
            IsCompatible = rabbit_queue_type:is_compatible(
                             Type, Durable, Exclusive, AutoDelete),
            case IsPermitted andalso IsCompatible of
                true ->
                    %% patch up declare arguments with x-queue-type if there                                                                                                                                                                                 
                    %% is a vhost default set the queue is durable and not exclusive                                                                                                                                                                         
                    %% and there is no queue type argument                                                                                                                                                                                                   
                    %% present                                                                                                                                                                                                                               
                    rabbit_misc:set_table_value(Args0,
                                                <<"x-queue-type">>,
                                                longstr,
                                                DefaultQueueType);
                false ->
                    Args0
            end;
...

The alternative would be to always patch the args and later fail.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants