[
https://issues.apache.org/jira/browse/KAFKA-15869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17788698#comment-17788698
]
Anton Agestam commented on KAFKA-15869:
---------------------------------------
Sorry for spamming here, I found the thread now in the non-Pony UI:
https://www.mail-archive.com/dev@kafka.apache.org/msg127971.html
> Document semantics of nullable nested API entities
> --------------------------------------------------
>
> Key: KAFKA-15869
> URL: https://issues.apache.org/jira/browse/KAFKA-15869
> Project: Kafka
> Issue Type: Wish
> Reporter: Anton Agestam
> Priority: Minor
>
> The initial version of ConsumerGroupHeartbeatResponse [introduced the first
> field across the protocol that is a nullable nested
> entity|https://github.com/dajac/kafka/blob/3acd87a3e82e1d2fd4c07218d362e7665b99c547/clients/src/main/resources/common/message/ConsumerGroupHeartbeatResponse.json#L48].
> As the implementor of a third-party schema parser it is not clear how to
> handle this field, where such fields are allowed, and how null is represented
> for such fields.
> As far as I can tell, the [protocol
> guide|https://kafka.apache.org/protocol.html#The_Messages_ConsumerGroupHeartbeat]
> does not mention the nullability at all.
> The reason I ask where such fields are allowed is because if the answer to
> how null is represented here is just omitting writing any bytes, then I
> suspect the only unambiguous place for such field to appear would be as the
> last field of a top-level entity. Even then, how is it discriminated from
> tagged fields?
> Is it possible this field was made nullable by mistake?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
