// Module included in the following assemblies:
//
// assembly-using-the-topic-operator.adoc

[id='con-application-topic-handling-{context}']
= Handling changes to topics

[role="_abstract"]
Configuration changes only go in one direction: from the `KafkaTopic` resource to the Kafka topic.
Any changes to a Kafka topic managed outside the `KafkaTopic` resource are reverted.

== Downgrading to a Strimzi version that uses internal topics to store topic metadata

If you are reverting back to a version of Strimzi earlier than 0.41, which uses internal topics for the storage of topic metadata, you still downgrade your Cluster Operator to the previous version, then downgrade Kafka brokers and client applications to the previous Kafka version as standard.

== Automatic creation of topics

Applications can trigger the automatic creation of topics in the Kafka cluster.
By default, the Kafka broker configuration `auto.create.topics.enable` is set to `true`, allowing the broker to create topics automatically when an application attempts to produce or consume from a non-existing topic.  
Applications might also use the Kafka `AdminClient` to automatically create topics.
When an application is deployed along with its `KafkaTopic` resources, it is possible that automatic topic creation in the cluster happens before the Topic Operator can react to the `KafkaTopic`.

The topics created for an application deployment are initially created with default topic configuration.
If the Topic Operator attempts to reconfigure the topics based on `KafkaTopic` resource specifications included with the application deployment, the operation might fail because the required change to the configuration is not allowed.
For example, if the change means lowering the number of topic partitions.
For this reason, it is recommended to disable `auto.create.topics.enable` in the Kafka cluster configuration.
