Optimize RedeliveryCount Handling Mechanism

[NiuBlibing]

Search before asking

• I searched in the issues and found nothing similar.

Motivation

Description

Currently, the message redelivery count (RedeliveryCount) only increases when the client actively calls the redeliver method #18239. However, in certain scenarios—such as when the program runs out of memory or crashes due to an unhandled exception—the message is not properly redelivered, and the count does not increase.

This can lead to messages being retried indefinitely without entering the dead-letter queue (DLQ), affecting system stability and failure recovery.

Optimization Proposal

It is recommended to move the logic for increasing RedeliveryCount from the client to the Broker side to ensure:

• When a message is consumed but not acknowledged (due to process crashes or other issues), the Broker correctly increments RedeliveryCount.
• Messages reach the dead-letter queue (DLQ) in a timely manner after exceeding the maximum retry limit, preventing infinite retries.

Solution

• Broker detects consumer disconnection and proactively increments RedeliveryCount.
• Client increases RedeliveryCount when receiving a message.

Alternatives

No response

Anything else?

No response

Are you willing to submit a PR?

• I'm willing to submit a PR!

[dao-jun]

In broker side, the redeliverycount also stores in the memory, which means once the broker restart or the topic unload, all the redeliverycount in memory will be clear and after the topic recover, it will all reset to 0. see: InMemoryRedeliveryTracker.

If we don't persist redeliverycount, this issue would be meaningless, but, if we persist it, will it bring any benefits? It's hard to say.

[thetumbled]

RedeliveryCount is maintained by broker, not client.