Good idea, and implemented in a straightforward fashion! Thanks for the PR - rolled into 7.0.4 now.

@jhoeller rabbitmq/rabbitmq-jms-client#698 bumps Spring to 7.0.4 and has a RPC test failing. I suspect this change to be the culprit. I see the reply consumer is now created after the message is sent, so the RPC server may send a reply before the temporary queue is created. The requester does not get any response then. Do you think this analysis is correct?

I reproduced the failure locally, but it is transient, which makes sense as there is a race condition.

The temporary Queue instance is technically created before the send operation still; it's just the MessageConsumer for that Queue that is created after the send now. Any insight into why RabbitMQ effectively creates the temporary queue on createConsumer there rather than on the actual createTemporaryQueue call? With ActiveMQ, the queue seems to exist in a stable form after createTemporaryQueue, with createConsumer then just starting delivery from the queue.

In any case, I'll revise this to differentiate between the useCorrelationId code path and the temporary queue path, performing the createConsumer call early in the latter case again (where we don't have to wait for a correlation/message id on the sent message). Let's track this in the derived issue: #36321