admin.ListTopics() returns unexpected config entries

[ZoltanOnody]

Versions

Sarama	Kafka	Go
1.24.0	2.1.1	1.12.7

Problem Description

I'm trying to desribe a topic using sarama but it gives me unexpected results.

When I run:

/opt/kafka/bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic test2GD6-operations-imf-GD6-E

I get the following response:

Topic:test2GD6-operations-imf-GD6-E PartitionCount:4 ReplicationFactor:3 Configs:retention.ms=604800000,min.insync.replicas=2
   ... <list of topics>

So it shows me that the config is retention.ms=604800000,min.insync.replicas=2 which is, in fact, correct.

However, when I try to describe the same config using sarama, I get different results. Running:

topics, _ := admin.ListTopics()
topic, _ := topics["test2GD6-operations-imf-GD6-E"]
p, _ := json.Marshal(topic.ConfigEntries)
fmt.Println(string(p))

Returns:

{
  "message.format.version":"2.1-IV2",
  "min.insync.replicas":"2",
  "retention.ms":"604800000",
  "segment.bytes":"1073741824"
}

It seems to me, that sarama is returning some default config options. I don't think that is expected as in [email protected]/admin.go:291 I see:

// only include non-default non-sensitive config
// (don't actually think topic config will ever be sensitive)
if entry.Default || entry.Sensitive {
    continue
}
topicDetails.ConfigEntries[entry.Name] = &entry.Value

[ghost]

Thank you for taking the time to raise this issue. However, it has not had any activity on it in the past 90 days and will be closed in 30 days if no updates occur.
Please check if the master branch has already resolved the issue since it was raised. If you believe the issue is still valid and you would like input from the maintainers then please comment to ask for it to be reviewed.

[d1egoaz]

It looks like expectation was changed here: #1514

[ghost]

Thank you for taking the time to raise this issue. However, it has not had any activity on it in the past 90 days and will be closed in 30 days if no updates occur.
Please check if the master branch has already resolved the issue since it was raised. If you believe the issue is still valid and you would like input from the maintainers then please comment to ask for it to be reviewed.