Wrong field values reported in CreateTopicsResponse (v5+)

[weeco]

Version & Environment

Redpanda version: (use rpk version): v23.2.19

What went wrong?

I used franz-go to send a CreateTopicsRequest with the following payload:

and I get the following response back:

The unexpected behaviour is:

1. NumPartitions is set to -1
2. ReplicationFactor is set to -1
3. It reports that cleanup.policy is set at the TopicSource, but it wasn't part of the request. The reported value of 1 is also odd.

What should have happened instead?

1. NumPartitions should report how many partitions were created for this topic. This is especially useful when requesting the default number of partitions.
2. ReplicationFactor should report how many replicas every partition has for this topic. This is especially useful when requesting the default number of partitions.
3. Configs should only report topic-level configs with their actual value. Since cleanup.policy was not set as part of the request it should not be part of the response. Also the value of 1 is an invalid entry, it should only allow delete, compact or compact,delete for this field.

How to reproduce the issue?

1. Send a CreateTopic request with v5+ (probably can use rpk)
2. Look at CreateTopic response

Additional information

Please attach any relevant logs, backtraces, or metric charts.

[oleiman]

Quick note before I forget - for the cleanup.policy config, 5 is the correct source here, mapping to "default config" in both Redpanda and Apache Kafka.

Other aspects of this issue are repro'ed, validated, and fixes are WIP.

[twmb]

@oleiman I think Martin is returning to the Value, not the Source -- the Value is "1", rather than "cleanup,delete"

[oleiman]

@oleiman I think Martin is returning to the Value, not the Source -- the Value is "1", rather than "cleanup,delete"

Yup, the numeric cleanup policy value has been fixed :)

reports that cleanup.policy is set at the TopicSource

I assumed this was referring to the Source property on the cleanup policy config in the response, but I might have misunderstood. Maybe @weeco can comment.