I think it's actually okay too. That is to add a new parameter `Map<String, String> messageIds` to `skipMessages`, with key as `ledgerId` and value as `entryId`.
However, `numMessages` is a required parameter, how should this part be designed well? - Set `numMessages` to -1 or 0? And execute the logic of `internalAcknowledgeMessage` only after setting `messageIds`? - Set `numMessages` to the size of `messageIds`, if this value is not equal to the size of `messageIds`, return an error? I think setting `numMessages` to -1 is a good way to handle this. Thanks, sinan PengHui Li <peng...@apache.org> 于2025年6月17日周二 02:53写道： > Since we already have an existing skipMessages API in the admin interface, > could we consider simply adding a parameter (e.g., a list of message IDs) > to support this use case? > > In my opinion, extending skipMessages is more appropriate than using > acknowledge, > as the messages being “canceled” haven’t actually been processed. While > both > operations are functionally similar under the hood, skipMessages > semantically > better represents the intent in this scenario. > > Regards, > Penghui > > On Mon, Jun 9, 2025 at 9:03 PM xiangying meng <xiangy...@apache.org> > wrote: > > > Hello, Sinan, > > > > I hold the opposite view on this matter. There is no need to provide > > the index parameter for this admin API, just as there is no need to > > add an index as a parameter for every interface that uses message ID > > as an input. > > > > If a user chooses to use an index instead of a message ID, they should > > maintain the mapping relationship between the message ID and the index > > themselves. Pulsar's APIs, however, should exclusively use the message > > ID as a parameter. > > > > PIP-415 exists exactly to assist users in maintaining this mapping > > relationship between message IDs and indices. > > > > BR, > > Xiangying > > >
