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)