RobertIndie commented on code in PR #1301:
URL: https://github.com/apache/pulsar-client-go/pull/1301#discussion_r1825478601
##########
pulsar/consumer.go:
##########
@@ -307,6 +307,14 @@ type Consumer interface {
// AckID the consumption of a single message, identified by its
MessageID
AckID(MessageID) error
+ // AckIDList the consumption of a list of messages, identified by their
MessageIDs
+ // Returns a map of MessageID to error, the keys are the MessageIDs
that failed to be acknowledged
+ // NOTE: When EnableBatchIndexAcknowledgment is false, if a message ID
represents a message in the batch,
+ // it will not be actually acknowledged by broker until all messages in
that batch are acknowledged via
+ // the AckID or AckIDList method.
+ // However, in this case, no error will be returned for that message ID
even if AckWithResponse is true.
+ AckIDList([]MessageID) map[MessageID]error
Review Comment:
> Users should not ignore any failed message IDs, that's why I return a map
error. I don't want users to call it like:
Yes. Users could handle it. And users should not call it like that.
Instead, I gave the example in my above comment:
```
if err != nil {
if ackErr, ok := err.(AckIDListError); ok {
for id, e := range ackErr {
fmt.Printf("Message ID %d: %s\n", id, e)
}
}
}
```
The users could check the failed messages ids my converting the error to
`AckIDListError`.
> If it returns error directly, in which case should users not convert it to
the AckIDListError?
So, if the error is nil, then the user doesn't need to conver it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
