feat: add support to NegativeAcknowledge in Consumer #263
Conversation
There was a problem hiding this comment.
Pull Request Overview
This pull request adds support for negative message acknowledgment to the DotPulsar library, enabling consumers to signal failed message processing for redelivery.
- Introduces NegativeAcknowledge methods in IConsumer, Consumer, and SubConsumer.
- Provides extension methods in ConsumerExtensions and updates test coverage for negative acknowledgment scenarios.
Reviewed Changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| tests/DotPulsar.Tests/Internal/ConsumerTests.cs | Added tests for single, multiple, partitioned topics, and reconnect scenarios. |
| src/DotPulsar/Internal/SubConsumer.cs | Implemented NegativeAcknowledge methods for handling unacknowledged messages. |
| src/DotPulsar/Internal/Consumer.cs | Added NegativeAcknowledge methods handling both single and grouped messages. |
| src/DotPulsar/Extensions/ConsumerExtensions.cs | Created extension for negative acknowledgment on IMessage. |
| src/DotPulsar/Abstractions/IConsumer.cs | Updated the interface with NegativeAcknowledge method signatures and documentation. |
Comments suppressed due to low confidence (1)
src/DotPulsar/Internal/Consumer.cs:443
- [nitpick] The lambda parameter in the GroupBy call is named the same as the outer messageIds collection, which could be confusing. Consider renaming the lambda parameter (e.g., to 'msg' or 'messageId').
var groupedMessageIds = messageIds.GroupBy(messageIds => messageIds.Topic);
| /// <summary> | ||
| /// Acknowledge the consumption of a single message using the MessageId. | ||
| /// </summary> | ||
| /// <summary> |
There was a problem hiding this comment.
There are duplicate
tags in the XML documentation for the acknowledgment methods. Consider removing the redundant tag to ensure clarity and adherence to XML documentation standards.
Copilot uses AI. Check for mistakes.
|
|
||
| public async ValueTask NegativeAcknowledge(MessageId messageId, CancellationToken cancellationToken) | ||
| { | ||
| var command = new CommandRedeliverUnacknowledgedMessages(); |
There was a problem hiding this comment.
We already have 'RedeliverUnacknowledgedMessages' on the IConsumer that does this. I haven't used negative acknowledge, but isn't it a client-side feature to have the same message delivered again in a specified TimeSpan? Meaning no interaction with the broker and enabling the user to set the TimeSpan?
There was a problem hiding this comment.
Although RedeliverUnacknowledgedMessages already exists in IConsumer, the NegativeAcknowledge functionality brings a level of granularity that can be very useful in scenarios where we do not want to request redelivery of all pending messages, but only those that have failed on time.
The NegativeAcknowledge method allows marking specific messages to be redelivered by the broker, also aligning with the official Apache Pulsar API and facilitating use cases where fine management of retries is important (for example, when some messages fail intermittently and we don't want to affect the rest of the backlog).
In this way, we give more control to the user over error and retry management, avoiding global behaviors that may be unnecessary or inefficient in certain consumption contexts.
What do you think about?
There was a problem hiding this comment.
We have two 'RedeliverUnacknowledgedMessages' methods. One to redeliver all and one where you can specify the messageIds you want redelivered?
pulsar-dotpulsar/src/DotPulsar/Abstractions/IConsumer.cs
Lines 62 to 70 in e2025a0
There was a problem hiding this comment.
You are right, currently there are two RedeliverUnacknowledgedMessages methods: one to redeliver all pending messages and another to specify the specific messageIds that you want to redeliver.
The difference I propose with NegativeAcknowledge is more conceptual and alignment with the official Apache Pulsar API. While RedeliverUnacknowledgedMessages is an explicit action requesting the redeliver of messages (either all or a selection), the NegativeAcknowledge method allows to signal message delivery failures in a more direct and “semantic” way, facilitating scenarios where the workflow requires marking certain messages for retry without necessarily manually managing the IDs to redeliver.
In addition, some Pulsar clients implement NegativeAcknowledge allowing retry to occur after a defined interval, which can be useful in cases of temporary/intermittent failures.
That said, if you consider that both methods (RedeliverUnacknowledgedMessages for specific IDs and all) already cover the use cases, we can close the topic here. If not, my proposal is to keep the discussion going to see if it brings value from the point of view of usability and alignment with the official API.
There was a problem hiding this comment.
Hi @ivan-ciklum, DotPulsar doesn’t aim to align with the "official" API, so unless this introduces new functionality — rather than just renaming methods for consistency — I won’t be able to merge it.
Issue: Support - Consumer.NegativeAcknowledge
Issue: Feature- Consumer.NegativeAcknowledge
This pull request introduces support for negative acknowledgment of messages in the
DotPulsarlibrary. The changes add functionality to allow consumers to notify the broker when messages are not processed successfully, enabling their redelivery. Below are the key changes grouped by theme:Interface and Extension Updates
NegativeAcknowledgemethods to theIConsumerinterface for single and multipleMessageIdobjects, allowing users to signal message redelivery.ConsumerExtensionsto simplify negative acknowledgment forIMessageobjects.Internal Implementation
NegativeAcknowledgemethods in theConsumerclass to handle single and multiple message acknowledgments, including logic for handling grouped sub-consumers.NegativeAcknowledgemethods in theSubConsumerclass to execute redelivery commands for unacknowledged messages using the broker's protocol.