[ https://issues.apache.org/jira/browse/KAFKA-15869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17788552#comment-17788552 ]
Anton Agestam commented on KAFKA-15869: --------------------------------------- [~dajac] Ah, thanks for pointing me in the right direction for this, implementing the protocol has unfortunately been lots of fumbling in darkness. Hopefully we can make it a better experience in the future. I've wondered more than once whether KIPs ought to have a mandated "How do we teach this" section, like Python's PEPs do. > 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)