The document has been updated, please review it again. https://github.com/apache/pulsar/pull/24370
Thanks, sinan PengHui Li <peng...@apache.org> 于2025年6月19日周四 07:32写道： > Hi SiNan, > > You can have a new method such as: > > void skipMessages(String topic, String subName, Map<String, String> > messageIds) > > Regards, > Penghui > > On Wed, Jun 18, 2025 at 6:56 AM SiNan Liu <liusinan1...@gmail.com> wrote: > > > 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 > > > > > > > > > >
