sanghyeok An created KAFKA-21211:
------------------------------------
Summary: Server-side Streams rack-aware assignment configuration
can accept tag keys longer than 20 characters, while the Kafka Streams client
rejects such keys during `StreamsConfig` construction.
Key: KAFKA-21211
URL: https://issues.apache.org/jira/browse/KAFKA-21211
Project: Kafka
Issue Type: Bug
Reporter: sanghyeok An
Assignee: sanghyeok An
*Description*
Server-side Streams rack-aware assignment configuration can accept tag keys
longer than 20 characters, while the Kafka Streams client rejects such keys
during {{StreamsConfig}} construction.
The inconsistency affects both configuration paths:
* Broker default: {{group.streams.rack.aware.assignment.tags}}
* Group override: {{streams.rack.aware.assignment.tags}}
For example, the server-side configuration accepts the following 22-character
tag key:
{{streams.rack.aware.assignment.tags=availability_zone_name}}
However, a Streams client cannot supply the corresponding tag:
* group.protocol=streams
* client.tag.availability_zone_name=az-a
{{StreamsConfig}} throws a {{ConfigException}} because the tag key exceeds the
client-side maximum length of 20 characters.
*Actual behavior*
The server accepts a rack-aware assignment tag key that the official Streams
client cannot provide. Adding the corresponding client tag prevents the
application from starting; omitting it leaves that tag unavailable to the
assignor.
*Expected behavior*
Server-side rack-aware assignment configuration should be consistent with the
tag keys supported by the Streams client. An unsupported key should be rejected
when the configuration is supplied, rather than accepted and discovered later
during client startup.
*Suggested fix*
Validate tag key lengths during broker bootstrap and Admin API group
configuration changes. Reject keys longer than 20 characters with a
{{ConfigException}} during bootstrap or the corresponding configuration error
through the Admin API. (It would be better to consider length of value - 30)
Compatibility with previously stored configurations should be considered,
particularly for configuration queries and metadata restoration.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
