Yes. This is discussed in the official Python tutorial:
A timeout (30 minutes by default) is enforced on consumer delivery acknowledgement. This helps detect buggy (stuck) consumers that never acknowledge deliveries.
You can find more information available on the RabbitMQ documentation for Delivery Acknowledgement Timeout
However, this was not always the case. Older versions of RabbitMQ (at least through version 3.6.x) did not provide any sort of timeout mechanism for acknowledging messages. This was mentioned in older versions of the official Python tutorial:
There aren’t any message timeouts; RabbitMQ will redeliver the message only when the worker connection dies. It’s fine even if processing a message takes a very, very long time.
Section 3.1.8 of the AMQP 0-9-1 specification describes Acknowledgements, and is very clear that they can either be Automatic (the client doesn’t have to do anything, messages are acknowledged as soon as they are delivered) or Explicit (the client must an Ack for each message or group of messages that it has processed).
Here’s some past discussion from back in 2009 confirming this behavior.
The first reference to changing this behavior that I can see is this PR from April 2019. I’m not sure what version of the server that change was included in, but it sounds like the default was initially “no timeout”, then 15 minutes in RabbitMQ 3.8.15, then 30 minutes in RabbitMQ 3.8.17 (where it remains as of October 2021).
So: This behavior is dependent on your version of RabbitMQ. Older versions required you to explicitly send NACKs after some interval. Newer versions have a default timeout.