I think there’s a lot of confusion in this space - I certainly had some for a while, and I can’t give the authoritative answer, but here is my understanding of what you’re seeing.
First, there is no timeout for acknowledgement. That is to say, redelivery is never triggered as a result of slow acknowledgement. Redelivery is only triggered if there’s no acknowldgement. That happens when a subscriber receives a message and then their flow is disconnected before acknowledgement happens (eg, the subscriber process crashes between receipt and acknowledgement). When the client reconnects, any messages that have already been sent, but for which no acknowledgement was received before the flow disconnected, will be retransmitted. So it’s the disconnection of the flow that matters, not how long you held the message for.
I think the reason you are seeing unpredictable behaviour is because of your Thread.Sleep() . It appears as though the code you have in your question is running inside the MessageEventHandler of the Flow . That means that you have a blocking wait inside your message event handler. But you cannot block the message event handler, because doing so blocks the internal processing going on in the Solace libraries. So what you’re probably seeing is an underlying TCP timeout based on loss of communication between the client and broker, and it’s that loss of connection which causes any sent-but-unacknowledged messages to be retransmitted to a different consumer.
See this thread for more details: Applying backpressure to a flow by blocking in the MessageEventHandler — Solace Community