1UpdateMetadataRequestTopicPartition => not top level, no encoding, flexible v6+
2 Topic: string // v0-v4
3 Partition: int32
4 ControllerEpoch: int32
5 Leader: int32
6 LeaderEpoch: int32
7 ISR: [int32]
8 ZKVersion: int32
9 Replicas: [int32]
10 OfflineReplicas: [int32] // v4+
11
12// UpdateMetadataRequest is an advanced request that brokers use to
13// issue metadata updates to each other.
14//
15// As this is an advanced request and there is little reason to issue it as a
16// client, this request is undocumented.
17//
18// Version 1 changed the layout of the live brokers.
19//
20// Kafka 2.2 introduced version 5, proposed in KIP-380, which changed the
21// layout of the struct to be more memory efficient.
22// Kafka 3.4 introduced version 8 with KIP-866.
23UpdateMetadataRequest => key 6, max version 8, flexible v6+
24 ControllerID: int32
25 // If KRaft controller id is used during migration. See KIP-866.
26 IsKRaftController: bool // v8+
27 ControllerEpoch: int32
28 BrokerEpoch: int64(-1) // v5+
29 PartitionStates: [UpdateMetadataRequestTopicPartition] // v0-v4
30 TopicStates: [=>] // v5+
31 Topic: string
32 TopicID: uuid // v7+
33 PartitionStates: [UpdateMetadataRequestTopicPartition]
34 LiveBrokers: [=>]
35 ID: int32
36 Host: string // v0-v0
37 Port: int32 // v0-v0
38 Endpoints: [=>] // v1+
39 Port: int32
40 Host: string
41 ListenerName: string // v3+
42 SecurityProtocol: int16
43 Rack: nullable-string // v2+
44
45// UpdateMetadataResponses is returned from an UpdateMetadataRequest.
46UpdateMetadataResponse =>
47 ErrorCode: int16
View as plain text