You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "showuon (via GitHub)" <gi...@apache.org> on 2023/05/24 08:02:47 UTC

[GitHub] [kafka] showuon commented on a diff in pull request #13747: MINOR: Fix ListOffsetsRequestTest.testResponseIncludesLeaderEpoch

showuon commented on code in PR #13747:
URL: https://github.com/apache/kafka/pull/13747#discussion_r1203646848


##########
core/src/test/scala/unit/kafka/server/ListOffsetsRequestTest.scala:
##########
@@ -192,7 +192,7 @@ class ListOffsetsRequestTest extends BaseRequestTest {
     killBroker(firstLeaderId)
     val secondLeaderId = TestUtils.awaitLeaderChange(servers, partition, firstLeaderId)
     // make sure high watermark of new leader has caught up
-    TestUtils.waitUntilTrue(() => sendRequest(secondLeaderId, 0L, -1).errorCode() != Errors.OFFSET_NOT_AVAILABLE.code(),
+    TestUtils.waitUntilTrue(() => sendRequest(secondLeaderId, ListOffsetsRequest.LATEST_TIMESTAMP, -1).errorCode != Errors.OFFSET_NOT_AVAILABLE.code,

Review Comment:
   So, if my understanding is correct, the test failure is because we are using the the `OFFSET_NOT_AVAILABLE` to identify if the new leader has caught up, but the `OFFSET_NOT_AVAILABLE` error only throws when requesting `LATEST_TIMESTAMP` or a timestamp beyond the last fetchable offset. Since we're using a small number of timestamp, this wait will pass immediately, and cause the below assertion failure with `OFFSET_NOT_AVAILABLE` sometimes. 
   
   Is this correct? If so, this change LGTM! Thanks.



-- 
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.

To unsubscribe, e-mail: jira-unsubscribe@kafka.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org