bschofield opened a new issue #6785: URL: https://github.com/apache/pulsar/issues/6785
As noted in [this comment](https://github.com/apache/pulsar/issues/3177#issuecomment-471866729), go code like this can cause a panic: ```golang id := msg.ID().Serialize() idParsed := pulsar.DeserializeMessageID(id) err := consumer.AckID(idParsed) ``` For me, the crash occurs in `pulsar-client-cpp/lib/MultiTopicsConsumerImpl.cc`, here: ```c++ const std::string& topicPartitionName = msgId.getTopicName(); std::map<std::string, ConsumerImplPtr>::iterator iterator = consumers_.find(topicPartitionName); ``` If we look at the definition of a `MessageId` in `pulsar-client-cpp/lib/MessageIdImpl.h`, we see that it contains four ints (partition, ledgerId, entryId, batchIndex) *and a private topic name*. When the go function `msg.ID().Serialize()` is called, it only stores the ints, not the topic name. Then, `pulsar.DeserializeMessageID(id)` only restores the ints, not the topic name. When the C++ code tries to ack a message ID constructed in this way, it crashes because the topic name is missing from the `MessageId` struct. This bug does not occur if we call `consumer.AckID(msg.ID())` directly on a `msg` returned from a consumer, because in that case the corresponding C++ `MessageId` _does_ have the topic name populated. It only occurs if we try to serialize and deserialize the ID. Unfortunately, because the results of calling `msg.ID()` directly can't be stored for any significant period of time (they are just wrappers to pointers, and the contents can be changed by the C++ client), this seems to be a serious issue which makes it impossible to ack messages for long-running tasks. ---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: [email protected]
