Hi,
following the resolution of issues #2941 and #3032, we have conducted a further analysis concerning the shutdown process within our custom requirements.

In our custom usage scenario, we customize the ShutdownTimeout, which is used within the shutdownAndWaitOrCallback() method to allow time for processing messages after the BasicCancel before the consumers stop.

However, the commit 02db80b has introduced a modification to the basicCancel() method's behavior. The invocation of RabbitUtils.closeMessageConsumer() now triggers a sequential execution of both the Cancel and the Recover operations.

To restore the previous behavior (with a timeout on shutdown), one potential solution would involve the introduction of a distinct timeout period between the execution of the BasicCancel and Recover commands.
Or, better yet, in our opinion, the basicCancel() method should be restored to its state before the change, and the Recover command should be added after waiting for the shutdown timeout.
I am referring to the shutdownAndWaitOrCallback() method after the instruction:
boolean finished = this.cancellationLock.await(this.getShutdownTimeout(), TimeUnit.MILLISECONDS);
if the result is false.

We are unaware of the reasoning behind the aforementioned change, so we are unsure of the most appropriate approach.
We do agree that, before the change, unacknowledged messages were never requeued in the case of channel transacted, but we think that the shutdown timeout should be anyway considered before the Recover.

What are your thoughts on this?