1// OffsetForLeaderEpochRequest requests log end offsets for partitions.
2//
3// Version 2, proposed in KIP-320 and introduced in Kafka 2.1.0, can be used by
4// consumers to perform more accurate offset resetting in the case of data loss.
5//
6// In support of version 2, this requires DESCRIBE on TOPIC.
7OffsetForLeaderEpochRequest => key 23, max version 4, flexible v4+
8 // ReplicaID, added in support of KIP-392, is the broker ID of the follower,
9 // or -1 if this request is from a consumer.
10 ReplicaID: int32(-2) // v3+
11 // Topics are topics to fetch leader epoch offsets for.
12 Topics: [=>]
13 // Topic is the name of a topic.
14 Topic: string
15 // Partitions are partitions within a topic to fetch leader epoch offsets for.
16 Partitions: [=>]
17 // Partition is the number of a partition.
18 Partition: int32
19 // CurrentLeaderEpoch, proposed in KIP-320 and introduced in Kafka 2.1.0,
20 // allows brokers to check if the client is fenced (has an out of date
21 // leader) or if the client is ahead of the broker.
22 //
23 // The initial leader epoch can be determined from a MetadataResponse.
24 CurrentLeaderEpoch: int32(-1) // v2+
25 // LeaderEpoch is the epoch to fetch the end offset for.
26 LeaderEpoch: int32
27
28// OffsetForLeaderEpochResponse is returned from an OffsetForLeaderEpochRequest.
29OffsetForLeaderEpochResponse =>
30 ThrottleMillis // v2+
31 // Topics are responses to topics in the request.
32 Topics: [=>]
33 // Topic is the topic this response corresponds to.
34 Topic: string
35 // Partitions are responses to partitions in a topic in the request.
36 Partitions: [=>]
37 // ErrorCode is the error code returned on request failure.
38 //
39 // TOPIC_AUTHORIZATION_FAILED is returned if the client does not have
40 // the necessary permissions to issue this request.
41 //
42 // KAFKA_STORAGE_ERROR is returned if the partition is offline.
43 //
44 // NOT_LEADER_FOR_PARTITION is returned if the broker knows of the partition
45 // but does not own it.
46 //
47 // UNKNOWN_TOPIC_OR_PARTITION is returned if the broker does not know of the
48 // partition.
49 //
50 // FENCED_LEADER_EPOCH is returned if the client is using a current leader epoch
51 // older than the actual leader epoch.
52 //
53 // UNKNOWN_LEADER_EPOCH if returned if the client is using a current leader epoch
54 // that the actual leader does not know of. This could occur when the client
55 // has newer metadata than the broker when the broker just became the leader for
56 // a replica.
57 ErrorCode: int16
58 // Partition is the partition this response is for.
59 Partition: int32
60 // LeaderEpoch is similar to the requested leader epoch, but pairs with the
61 // next field. If the requested leader epoch is unknown, this is -1. If the
62 // requested epoch had no records produced during the requested epoch, this
63 // is the first prior epoch that had records.
64 LeaderEpoch: int32(-1) // v1+
65 // EndOffset is either (1) just past the last recorded offset in the
66 // current partition if the broker leader has the same epoch as the
67 // leader epoch in the request, or (2) the beginning offset of the next
68 // epoch if the leader is past the requested epoch. The second scenario
69 // can be seen as equivalent to the first: the beginning offset of the
70 // next epoch is just past the final offset of the prior epoch.
71 //
72 // (2) allows consumers to detect data loss: if the consumer consumed
73 // past the end offset that is returned, then the consumer should reset
74 // to the returned offset and the consumer knows everything past the end
75 // offset was lost.
76 //
77 // With the prior field, consumers know that at this offset, the broker
78 // either has no more records (consumer is caught up), or the broker
79 // transitioned to a new epoch.
80 EndOffset: int64(-1)
View as plain text