Add case to concurrent queue delete

[25schmekles]

If ra:delete_cluster/2 calls overlap the Ra cluster is found mid-shutdown and a {error, {shutdown, delete}} is raised.

During a concurrent queue or vhost delete, if there is an overlap, this case can miss {error, {shutdown, delete}} and crash even though the queue is being successfully deleted.

rabbitmq-server/deps/rabbit/src/rabbit_quorum_queue.erl

Line 1099 in b8a3ae5

case ra:delete_cluster(Servers, Timeout) of

[michaelklishin]

@25schmekles I'm afraid we won't rush to implement a suggestion with a two sentence description and no details on how to reproduce a behavior and why it is worth our small team's time.

[25schmekles]

And rightly so. Let me elaborate a little.

As I understand it, in this situation the queue is being successfully removed. So, it seems like {shutdown, delete} should be handled as an expected state, eliminating crash/error logging.

Admittedly, this is a low priority/impact issue.

Steps to Reproduce

This is a bit of a race condition and tends to surfaces during automated removal of a vhost.

1. Create a vhost with multiple quorum queues
2. Issue a queue delete from 2 or more nodes simultaneously
3. The unmatched return value should crash the delete operation

Fix

Add a clause in rabbit_quorum_queue:delete/4 to handle {error, {shutdown, delete}}:

• Log INFO/DEBUG that the cluster was already shutting down
• Notify decorators (idempotent — returns ok if queue record is gone)
• Clean up queue metadata via delete_queue_data
• Call rabbit_core_metrics:queue_deleted/1 locally to prevent stale entries in the management UI

I'm happy to open a PR if this seems reasonable.