rpc core should abort a call() early if the connection is terminated before the timeout period expires

I think this really is an olso.messaging bug, these things are mostly left up to that lib at this point

Does the client not reconnect, or does the reconnection not fix the issue somehow?

The client waits for the full RPC timeout period (60 secs by default) and then reconnects. However, in an HA environment the newly-active rabbitmq server will be up and available long before then.

Also, on a controlled switchover the rabbitmq server will have done a formal shutdown of the connection which would notify the client that the connection is being shut down. Something on the client should notice that the server has gone away long before the RPC timeout is over, and alert anyone waiting for an RPC response that they're never going to get one.

Client can reconnect to another rabbitmq-server if one of rabbitmq-server that the client is connecting is down(if you configure multiple rabbitmq-servers by enabling rabbit_hosts or haproxy like proxy), and rabbitmq-servers in a cluster hold the synchronized infos, msgs etc
Did I missed something? @Sean Dague

There is a new feature in oslo.messaging that will detect the loss of the message bus and immediately raise a message delivery failure.

https://git.openstack.org/cgit/openstack/oslo.messaging/tree/releasenotes/notes/RPC-call-monitoring-7977f047d069769a.yaml

This new feature should address this issue - moving bug to 'in-progress'

This will probably reduce the time window, but it seems weird that the client is essentially ignoring the socket shutdown during a controlled failover.

Fair point, and a good question.
Let's keep this open as a separate bug - need to determine how the pyamqp library surfaces the socket close event.