Proposed Changes

ra:key_metrics/1 can return a very small metrics map in case a member is dead and it terminated so early that it hasn't recorded any counters yet.

In this edge case the quorum_status command used to crash, although returning status of other members is still useful.

$ rabbitmq-queues quorum_status <queue>
Status of quorum queue <queue> on node rabbit@<host> ...
Error:
{{:case_clause, %{state: :noproc, membership: :unknown, machine_version: 6}}, [{:rabbit_quorum_queue, :"-status/2-lc$^0/1-0-", 2, [file: ~c"src/rabbit_quorum_queue.erl", line: 1252]}, {:rabbit_quorum_queue, :"-status/2-lc$^0/1-0-", 2, [file: ~c"src/rabbit_quorum_queue.erl", line: 1311]}, {:rabbit_quorum_queue, :status, 2, []}]}

Types of Changes

What types of changes does your code introduce to this project?
Put an x in the boxes that apply

• Bug fix (non-breaking change which fixes issue #NNNN)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause an observable behavior change in existing systems)
• Documentation improvements (corrections, new content, etc)
• Cosmetic change (whitespace, formatting, etc)
• Build system and/or CI

Checklist

Put an x in the boxes that apply.
You can also fill these out after creating the PR.
This is simply a reminder of what we are going to look for before merging your code.

• Mandatory: I (or my employer/client) have have signed the CA (see https://github.com/rabbitmq/cla)
• I have read the CONTRIBUTING.md document
• I have added tests that prove my fix is effective or that my feature works
• All tests pass locally with my changes
• If relevant, I have added necessary documentation to https://github.com/rabbitmq/rabbitmq-website
• If relevant, I have added this change to the first version(s) in release-notes that I expect to introduce it

Further Comments