With this change and the default64 set here (just a sensible-seeming constant) I see my test in#15057 of shrinking from 1000 QQs go from taking ~2hrs to taking 1min52sec.

This looks fine to me, at least for now.

It would be quite possible to get much higher throughput on this and use command pipelining instead of spawning a bunch of processes just to exercise the WAL more. We'd need to add that as an option to the Ra API however.

Ah yeah, with pipelining we could use the WAL much more efficiently. That shouldn't be too bad to add to Ra - just a new function inra that would usera_server_proc:cast_command/3, right? Once mnesia is gone we could use Khepri async commands for the metadata store updates so both of those parts could be done with pipelining.

I'm actually more worried about thera:force_delete_server/2 part since that step can take a while (7 seconds) if the connection to the node times out. An easy way around that would be adding a function inrabbit_quorum_queue to callra:force_delete_server/2 on all queues after the membership and metadata store parts are done. Then it would just be one RPC call which could time out.

In the meantime making this parallel seems like an easy improvement since we can continue using thedelete_member/2 helper. But in the long run we should definitely use pipelining instead 👍