Hi SiNan, LGTM, left a comment about the REST API definition.
Regards, Penghui On Thu, Jul 17, 2025 at 7:13 AM SiNan Liu <liusinan1...@gmail.com> wrote: > 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 > > > > > > > > > > > > > > >
