[refactor]: Refactor the toTrackingMessageID()

[Gleiphir2769]

Motivation

toTrackingMessageID() is a function that is widely used in consumer implementation. It can convert an interface type MessageID into an struct type trackingMessageID. In addition, the second return value also plays a role in checking the MessageID type. In other words, it indicates that MessageID cannot be a user-defined type. From the perspective of code readability, toTrackingMessageID() should not do both.

Note: After #968 , toTrackingMessageID() returns only a pointer now. The role of original ok is replaced by nil pointer now. However, the main content discussed in this PR has not changed.

For example.

pulsar-client-go/pulsar/consumer_regex.go

Lines 176 to 181 in e2ea255

	func (c *regexConsumer) AckID(msgID MessageID) error {
	mid, ok := toTrackingMessageID(msgID)
	if !ok {
	c.log.Warnf("invalid message id type %T", msgID)
	return errors.New("invalid message id type")
	}

This example is the correct usage. The ok returned by toTrackingMessageID() is used to reject user-defined MessageID.

pulsar-client-go/pulsar/consumer_partition.go

Lines 470 to 473 in e2ea255

	trackingID, ok := toTrackingMessageID(msgID)
	if !ok {
	return errors.New("failed to convert trackingMessageID")
	}

This example is a bit vague. The actual effect here is the same as the previous example. But it return an error failed to convert trackingMessageID which is confusing.

pulsar-client-go/pulsar/consumer_partition.go

Lines 1816 to 1820 in e2ea255

	for _, mid := range c.chunkedMsgIDs {
	pc.log.Info("Removing chunk message-id", mid.String())
	tmid, _ := toTrackingMessageID(mid)
	pc.AckID(tmid)
	}

In this case. We just want to convert MessageID into trackingMessageID. We do not care what it really is because it's not possible an invalid MessageID implementation.

So, original toTrackingMessageID() needs to require a careful look to use it correctly. I think it would be better to split it into two different method. toTrackingMessageID() just do the struct conversion, which it's more clearly. And when the new messageID type is added, we can just modify the checkMessageIDType.

Modifications

• Refactor the toTrackingMessageID()
• Add the checkMessageIDType() to check whether MessageID is user-defined.

Verifying this change

• Make sure that the change passes the CI checks.

Documentation

• Does this pull request introduce a new feature? no

[Gleiphir2769]

Hi @BewareMyPower @RobertIndie @nodece @shibd, could you give a look when you are free?

[Gleiphir2769]

/pulsarbot run-failure-checks

[Gleiphir2769]

/pulsarbot run-failure-checks

Still doesn't work...

[BewareMyPower]

The flaky test is related to #971

[Gleiphir2769]

The flaky test is related to #971

@BewareMyPower yes, rerun CI failed again. Looks like CI is stucked in TestConsumerSeekByTimeOnPartitionedTopic now.

[BewareMyPower]

I will review it tomorrow

[shibd]

Even if we check the type of msgID, we can't remove this check, because there is other logic that returns nil

pulsar-client-go/pulsar/consumer_impl.go

Lines 755 to 759 in 48b7d01

	if partition < 0 || partition >= len(c.consumers) {
	c.log.Warnf("invalid partition index %d expected a partition between [0-%d]",
	partition, len(c.consumers))
	return nil
	}

We can add checkMessageIdType to c. messageID method, and keep this check.

[Gleiphir2769]

Great suggestion! I will fix it.