Flaky-test: TopicReaderTest.testHasMessageAvailable

[lhotari]

TopicReaderTest.testHasMessageAvailable is flaky

example failure:

Error:  Tests run: 46, Failures: 1, Errors: 0, Skipped: 2, Time elapsed: 367.157 s <<< FAILURE! - in org.apache.pulsar.client.api.TopicReaderTest
Error:  testHasMessageAvailable(org.apache.pulsar.client.api.TopicReaderTest)  Time elapsed: 3.903 s  <<< FAILURE!
java.lang.AssertionError: expected [true] but found [false]
	at org.testng.Assert.fail(Assert.java:99)
	at org.testng.Assert.failNotEquals(Assert.java:1037)
	at org.testng.Assert.assertTrue(Assert.java:45)
	at org.testng.Assert.assertTrue(Assert.java:55)
	at org.apache.pulsar.client.api.TopicReaderTest.testHasMessageAvailable(TopicReaderTest.java:973)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
	at org.testng.internal.InvokeMethodRunnable.runOne(InvokeMethodRunnable.java:45)
	at org.testng.internal.InvokeMethodRunnable.call(InvokeMethodRunnable.java:73)
	at org.testng.internal.InvokeMethodRunnable.call(InvokeMethodRunnable.java:11)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

[315157973]

I checked this and found it to be a bug. Now the broker has an ackSet to record the ack position of a message in BatchMessage. But the client did not return this ack position when calling GetLastMessageId. This will happen:
The MessagId of seek is 3:31:-1:0 and the lastMessageIdInBroker is 3:31:-1.
Therefore, when compareTo is called, it must return <0, which causes hasMessageAvailable to return false.
When the producer starts batch sending, if the returned message is BatchMessageId, this problem will be triggered. If it is MessageIdImpl, it will pass the test.
I will try to fix it