Hi Pulsar Community, In Pulsar 2.5.0, the semantics for a message's redeliveryCount changed at the request of this issue [0]. Please see the issue for relevant context.
In summary, the issue is whether a message that is neither positively nor negatively acknowledged should get counted as "redelivered" when a consumer disconnects from the broker. The issue asserts that because a message could lead to a fatal error in the consumer application that could prevent negative acknowledgement getting sent to the broker, every delivery of a message should count towards the redeliveryCount. In my view, this edge case should not justify changing the redeliveryCount semantics. It is the responsibility of the application to handle all messages, even those that are malformed. My primary motivation for revisiting this design is to discuss one of its consequences. After the change, messages that are only ever sent to an application's receiverQueue are counted against the delivery count used to determine whether a message ought to go to the DLQ topic. Because the DLQ implementation uses the redeliveryCount to determine when a message has been attempted "enough" times, there is a chance that messages can get sent to the DLQ without ever having been "received" by the consuming application. While this scenario is unlikely, I think it introduces doubt into this feature's design because it is possible for messages to get classified as dead letters without delivery at least the maxRedeliverCount. Here is my PR to adopt the original behavior [1]. Please take a look. Thanks, Michael [0] https://github.com/apache/pulsar/issues/5881 [1] https://github.com/apache/pulsar/pull/17060
