chia7712 commented on code in PR #16841:
URL: https://github.com/apache/kafka/pull/16841#discussion_r1715842281


##########
server-common/src/main/java/org/apache/kafka/server/common/MetadataVersion.java:
##########
@@ -244,7 +244,7 @@ public enum MetadataVersion {
      * <strong>Think carefully before you update this value. ONCE A METADATA 
VERSION IS PRODUCTION,
      * IT CANNOT BE CHANGED.</strong>
      */
-    public static final MetadataVersion LATEST_PRODUCTION = IBP_3_8_IV0;
+    public static final MetadataVersion LATEST_PRODUCTION = IBP_3_9_IV0;

Review Comment:
   > However, by default, v9 of ListOffset is not supported with 
latestVersionUnstable set to true. So, I still don't understand why some 
existing tests don't fail. We probably need to understand the testing gap. If 
we have sufficient test coverage, we probably don't need additional protocols.
   
   yes, you are right. we should have a test for replica path. I just write a 
IT which can produce following error when LIST_OFFSET has unstable version:
   ```
   [2024-08-14 03:27:13,119] ERROR Closing socket for 
127.0.0.1:36885-127.0.0.1:48854-3 because of error (kafka.network.Processor:76)
   org.apache.kafka.common.errors.InvalidRequestException: Received request api 
key LIST_OFFSETS with version 9 which is not enabled
   ```
   Also, it seems we create IT with unstable APIs always [0] and I guess that 
is why we don't see failed tests.
   
   **Summary**
   1. broker-to-broker: the LIST_OFFSET version is based on MV [1], and we use 
IT to protect us from updating MV with an unstable version 
(https://issues.apache.org/jira/browse/KAFKA-17336)
   2. new-client-to-old-broker: the builder of LIST_OFFSET will check the 
timestamp and its matched version 
(https://issues.apache.org/jira/browse/KAFKA-17331)
   3. old-client-to-new-broker: the broker will check the timestamp and its 
matched version (https://issues.apache.org/jira/browse/KAFKA-17331)
   
   
   > I didn't realize ListOffset was being used in the replication path. I 
guess this is just for tiered storage.
   
   @jolshan not really, the request is used to truncate in the replication 
path. I have attached a sample code in 
https://issues.apache.org/jira/browse/KAFKA-17336. we will complete it tomorrow.
   
   [0] 
https://github.com/apache/kafka/blob/8d29bc1fa8ce75b6807b957ea35ad39e8dd9e04a/core/src/test/scala/unit/kafka/utils/TestUtils.scala#L307
   [1] 
https://github.com/apache/kafka/blob/8d29bc1fa8ce75b6807b957ea35ad39e8dd9e04a/server-common/src/main/java/org/apache/kafka/server/common/MetadataVersion.java#L474
   
   



-- 
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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to