Partition numbers about franz-go HOT 3 CLOSED

The primary reason is KIP-482 introduced tag sections at the end of every struct. Before that, I did embed some simple fields (commit 9574f35 changed this). If Kafka has something as a struct, it must be encoded as a struct so that it can {,de}serialize properly with a tag section.

w.r.t. deviation / missing: Kafka does not need to reply in order. For metadata and create topic, it always replies with all partitions. I think Kafka would have to be buggy to have missing partitions when the response is supposed to include all partitions. When a request specifies individual partitions, responses for only those partitions are returned.

from franz-go.

Ah yes it should be safe!... should be. I usually avoid that assumption out of input paranoia but it should be safe when talking to non-buggy Kafka's.

from franz-go.

I see. Thank you for the explanation. It seems like Kafka should always return contiguous partition numbers that are 0-indexed so it would be safe to store the assignments in a [][]int32 array.

e.g.

         // Where `partitions` is type []kmsg.MetadataResponseTopicPartition
	assignments := make([][]int32, len(partitions))
	for _, p := range partitions {
		assignments[p.Partition] = p.Replicas
	}

from franz-go.