// ListOffsetsRequest requests partition offsets from Kafka for use in
// consuming records.
//
// Version 5, introduced in Kafka 2.2.0, is the same as version 4. Using
// version 5 implies you support Kafka's OffsetNotAvailableException
// See KIP-207 for details.
//
// Version 7, introduced in Kafka 3.0, supports -3 as a timestamp to return
// the timestamp and offset for the record with the largest timestamp.
//
// Version 8, introduced in Kafka 3.4, supports -4 as a timestamp to return
// the local log start offset (in the context of tiered storage, see KIP-405).
ListOffsetsRequest => key 2, max version 8, flexible v6+
  // ReplicaID is the broker ID to get offsets from. As a Kafka client, use -1.
  // The consumer replica ID (-1) causes requests to only succeed if issued
  // against the leader broker.
  ReplicaID: int32(-1)
  // IsolationLevel configures which record offsets are visible in the
  // response. READ_UNCOMMITTED (0) makes all records visible. READ_COMMITTED
  // (1) makes non-transactional and committed transactional records visible.
  // READ_COMMITTED means all offsets smaller than the last stable offset and
  // includes aborted transactions (allowing consumers to discard aborted
  // records).
  IsolationLevel: int8 // v2+
  // Topics is an array of topics to get offsets for.
  Topics: [=>]
    // Topic is a topic to get offsets for.
    Topic: string
    // Partitions is an array of partitions in a topic to get offsets for.
    Partitions: [=>]
      // Partition is a partition of a topic to get offsets for.
      Partition: int32
      // CurrentLeaderEpoch, proposed in KIP-320 and introduced in Kafka 2.1.0,
      // allows brokers to check if the client is fenced (has an out of date
      // leader) or is using an unknown leader.
      //
      // The initial leader epoch can be determined from a MetadataResponse.
      // To skip log truncation checking, use -1.
      CurrentLeaderEpoch: int32(-1) // v4+
      // Timestamp controls which offset to return in a response for this
      // partition.
      //
      // The offset returned will be the one of the message whose timestamp is
      // the first timestamp greater than or equal to this requested timestamp.
      //
      // If no such message is found, then no offset is returned (-1).
      //
      // There exist two special timestamps: -2 corresponds to the earliest
      // timestamp, and -1 corresponds to the latest.
      //
      // If you are talking to Kafka 3.0+, there exists an additional special
      // timestamp -3 that returns the latest timestamp produced so far and its
      // corresponding offset. This is subtly different from the latest offset,
      // because timestamps are client-side generated. More importantly though,
      // because this returns the latest produced timestamp, this can be used
      // to determine topic "liveness" (when was the last produce?).
      // Previously, this was not easy to determine. See KIP-734 for more
      // detail.
      //
      // If you are talking to Kafka 3.4+ and using request version 8+ (for
      // KIP-405), the new special timestamp -4 returns the local log start
      // offset. In the context of tiered storage, the earliest local log start
      // offset is the offset actually available on disk on the broker.
      Timestamp: int64
      // MaxNumOffsets is the maximum number of offsets to report.
      // This was removed after v0.
      MaxNumOffsets: int32(1) // v0-v0

// ListOffsetsResponse is returned from a ListOffsetsRequest.
ListOffsetsResponse =>
  ThrottleMillis(3) // v2+
  // Topics is an array of topic / partition responses corresponding to
  // the requested topics and partitions.
  Topics: [=>]
    // Topic is the topic this array slot is for.
    Topic: string
    // Partitions is an array of partition responses corresponding to
    // the requested partitions for a topic.
    Partitions: [=>]
      // Partition is the partition this array slot is for.
      Partition: int32
      // ErrorCode is any error for a topic partition in a ListOffsets request.
      //
      // TOPIC_AUTHORIZATION_FAILED is returned if the client is not authorized
      // to describe the topic.
      //
      // INVALID_REQUEST is returned if the requested topic partitions had
      // contained duplicates.
      //
      // KAFKA_STORAGE_EXCEPTION is returned if the topic / partition is in
      // an offline log directory.
      //
      // UNSUPPORTED_FOR_MESSAGE_FORMAT is returned if the broker is using
      // Kafka 0.10.0 messages and the requested timestamp was not -1 nor -2.
      //
      // NOT_LEADER_FOR_PARTITION is returned if the broker is not a leader
      // for this partition. This means that the client has stale metadata.
      // If the request used the debug replica ID, the returned error will
      // be REPLICA_NOT_AVAILABLE.
      //
      // UNKNOWN_TOPIC_OR_PARTITION is returned if the broker does not know
      // of the requested topic or partition.
      //
      // FENCED_LEADER_EPOCH is returned if the broker has a higher leader
      // epoch than what the request sent.
      //
      // UNKNOWN_LEADER_EPOCH is returned if the request used a leader epoch
      // that the broker does not know about.
      //
      // OFFSET_NOT_AVAILABLE, introduced in Kafka 2.2.0 with produce request
      // v5+, is returned when talking to a broker that is a new leader while
      // that broker's high water mark catches up. This avoids situations where
      // the old broker returned higher offsets than the new broker would. Note
      // that if unclean leader election is allowed, you could still run into
      // the situation where offsets returned from list offsets requests are
      // not monotonically increasing. This error is only returned if the
      // request used the consumer replica ID (-1). If the client did not use
      // a v5+ list offsets request, LEADER_NOT_AVAILABLE is returned.
      // See KIP-207 for more details.
      ErrorCode: int16
      // OldStyleOffsets is a list of offsets. This was removed after
      // version 0 and, since it is so historic, is undocumented.
      OldStyleOffsets: [int64] // v0-v0
      // If the request was for the earliest or latest timestamp (-2 or -1), or
      // if an offset could not be found after the requested one, this will be -1.
      Timestamp: int64(-1) // v1+
      // Offset is the offset corresponding to the record on or after the
      // requested timestamp. If one could not be found, this will be -1.
      Offset: int64(-1) // v1+
      // LeaderEpoch is the leader epoch of the record at this offset,
      // or -1 if there was no leader epoch.
      LeaderEpoch: int32(-1) // v4+