You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Antonio Pires (Jira)" <ji...@apache.org> on 2020/05/22 13:36:00 UTC

[jira] [Created] (KAFKA-10032) Response to ApiVersionRequest returns wrong Produce(0) version

Antonio Pires created KAFKA-10032:
-------------------------------------

             Summary: Response to ApiVersionRequest returns wrong Produce(0) version
                 Key: KAFKA-10032
                 URL: https://issues.apache.org/jira/browse/KAFKA-10032
             Project: Kafka
          Issue Type: Bug
    Affects Versions: 2.4.0, 0.11.0.0
            Reporter: Antonio Pires


The response to {{ApiVersionRequest}} returns incorrect information for the Production {{_ApiKey_}} as it is not considering {{_log.message.format.version_}} config when being overwritten. While the internals, {{_Log.append()_}}, use {{log.message.format.version}} when adding a new record set to the active segment, the version exposed to clients is not the same, which can generate unexpected behaviour.

For example
 Using version _>0.11.0_ with {{_log.message.format.version_}} set to a previous version (0.10.2), the broker returns

{{(id: 1 rack: null) -> (}}
 {{    Produce(0): 0 to 3 [usable: 3],}}
 {{    Fetch(1): 0 to 5 [usable: 5],}}
 {{    ...}}
 \{{ )}}

and should instead be responding with

{{(id: 1 rack: null) -> (}}
 {{    Produce(0): 0 to 2 [usable: 2],}}
 {{    Fetch(1): 0 to 5 [usable: 5],}}
 {{    ...}}
 \{{ )}}

Shouldn't a single source of truth be used to get this version?
 In {{_Log.append()_}}, instead of directly getting the version from the config, shouldn't we use the {{_ApiVersions.maxUsableProduceMagic()_}} that, in turn, should take the config in consideration.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)