crossoverJie commented on code in PR #1301:
URL: https://github.com/apache/pulsar-client-go/pull/1301#discussion_r1825580483
##########
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:
> Can we return the `error` directly to simplify this API? And we can also
define the error type like this to let users get more specified errors for each
msg ids:
>
> ```go
> type AckIDListError map[MessageID]error
>
> func (e AckIDListError) Error() string {
> return "some message IDs failed to be acknowledged"
> }
> ```
>
> This way, the user can process the error like this:
>
> ```go
> if err != nil {
> if ackErr, ok := err.(AckIDListError); ok {
> for id, e := range ackErr {
> fmt.Printf("Message ID %d: %s\n", id, e)
> }
> }
> }
> ```
I guess many users will habitually directly judge `err != nil` and then
print out the err information.
Maybe this would be better(or somthine about more infomations):
```go
type AckIDListError map[MessageID]error
func (e AckIDListError) Error() string {
ids := make([]MessageID, 0)
for id, err := range e {
if err != nil{
ids = append(ids, id)
}
}
return fmt.Sprintf("some message IDs %s failed to be acknowledged", ids)
}
```
--
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]
