# autoCreateTopics problems in k2k kafka replication configuration for MSK Serverless

**URL:** <https://ask.lenses.io/t/autocreatetopics-problems-in-k2k-kafka-replication-configuration-for-msk-serverless/406>\
**Category:** K2K\
**Created:** [July 24, 2025, 11:26am UTC](https://ask.lenses.io/t/autocreatetopics-problems-in-k2k-kafka-replication-configuration-for-msk-serverless/406 "2025-07-24T11:26:41Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![james1985](https://avatars.discourse-cdn.com/v4/letter/j/c57346/32.png) [@james1985](https://ask.lenses.io/u/james1985)\
**Post date:** [July 24, 2025, 11:26am UTC](https://ask.lenses.io/t/autocreatetopics-problems-in-k2k-kafka-replication-configuration-for-msk-serverless/406/1 "2025-07-24T11:26:41Z")

</div>

Seems like when I try to set `autoCreateTopics` on k2k config, such as:

```auto
name: "test-k2k"
features:
  autoCreateControlTopics: enabled
  autoCreateTopics: enabled
coordination:
  kafka:

```

…I’m getting the errors:

```auto
00.0, 5000.0, 7500.0, 10000.0], getCounts=[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2], getExemplars=[]}, ImmutableHistogramPointData{getStartEpochNanos=1753355849817497766, getEpochNanos=1753355851885144572, getAttributes={arena="Main", thread.name="kafka-admin-client-thread | adminclient-1"}, getSum=581064.0, getCount=17, hasMin=true, getMin=7184.0, hasMax=true, getMax=262160.0, getBoundaries=[0.0, 5.0, 10.0, 25.0, 50.0, 75.0, 100.0, 250.0, 500.0, 750.0, 1000.0, 2500.0, 5000.0, 7500.0, 10000.0], getCounts=[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 2, 14], getExemplars=[]}, ImmutableHistogramPointData{getStartEpochNanos=1753355849817497766, getEpochNanos=1753355851885144572, getAttributes={arena="TLAB", thread.name="io-compute-1"}, getSum=372240.0, getCount=1, hasMin=true, getMin=372240.0, hasMax=true, getMax=372240.0, getBoundaries=[0.0, 5.0, 10.0, 25.0, 50.0, 75.0, 100.0, 250.0, 500.0, 750.0, 1000.0, 2500.0, 5000.0, 7500.0, 10000.0], getCounts=[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1], getExemplars=[]}]}}
k2k_1 | 11:17:31.992 [io-compute-0] ERROR io.lenses.k2k.main.Main - K2K application stopped with an unexpected exception.
k2k_1 | org.apache.kafka.common.errors.InvalidPartitionsException: Number of partitions is below 1.

```

```auto

k2k_1 | 11:22:09.527 [io-compute-1] ERROR io.lenses.k2k.main.Main - K2K application stopped with an unexpected exception.
k2k_1 | org.apache.kafka.common.errors.InvalidConfigurationException: Amazon MSK Serverless can't alter topic configuration file.delete.delay.ms. Only the following topic configurations are alterable: [compression.type, max.message.bytes, message.timestamp.difference.max.ms, message.timestamp.type, retention.bytes, retention.ms, cleanup.policy]. For all topic configurations, MSK Serverless uses defaults that follow best practices.

```

---

<div class="post-metadata">

**Author:** ![guillaume.ayme](https://dub1.discourse-cdn.com/flex017/user_avatar/ask.lenses.io/guillaume.ayme/32/64_2.png) [@guillaume.ayme](https://ask.lenses.io/u/guillaume.ayme)\
**Post date:** [July 29, 2025, 8:17pm UTC](https://ask.lenses.io/t/autocreatetopics-problems-in-k2k-kafka-replication-configuration-for-msk-serverless/406/2 "2025-07-29T20:17:23Z")

</div>

Setting this should work:

```auto
topicCreation:
  replication:
    common:
      config:
        "file.delete.delay.ms": null

```

---

<div class="post-metadata">

**Author:** ![guillaume.ayme](https://dub1.discourse-cdn.com/flex017/user_avatar/ask.lenses.io/guillaume.ayme/32/64_2.png) [@guillaume.ayme](https://ask.lenses.io/u/guillaume.ayme)\
**Post date:** [July 29, 2025, 8:18pm UTC](https://ask.lenses.io/t/autocreatetopics-problems-in-k2k-kafka-replication-configuration-for-msk-serverless/406/3 "2025-07-29T20:18:36Z")

</div>

…full example:

```auto
name: "my-first-replication"
features:
  autoCreateControlTopics: enabled
  autoCreateTopics: enabled
source:
  kafka:
    connection:
      servers: "kafka-source:9092"
    consumer:
      "group.id": "k2k.my-first-k2k"
target:
  kafka:
    connection:
      servers: "kafka-target:9092"
coordination:
  kafka:
    commit:
      group: "k2k.my-first-k2k"
replication:
  - source:
      topic: ".*"
  - sink:
      topic: source
      partition: source
topicCreation:
  replication:
    common:
      config:
        "file.delete.delay.ms": null

```

---

<div class="post-metadata">

**Author:** ![james1985](https://avatars.discourse-cdn.com/v4/letter/j/c57346/32.png) [@james1985](https://ask.lenses.io/u/james1985)\
**Post date:** [July 30, 2025, 9:01am UTC](https://ask.lenses.io/t/autocreatetopics-problems-in-k2k-kafka-replication-configuration-for-msk-serverless/406/4 "2025-07-30T09:01:58Z")

</div>

Now also getting the error:

`k2k_1 | 20:08:32.997 [io-compute-blocker-0] ERROR io.lenses.k2k.main.Main - K2K application stopped with an unexpected exception. k2k_1 | org.apache.kafka.common.errors.InvalidConfigurationException: Unknown topic config name: partition.size.max.bytes`

---

<div class="post-metadata">

**Author:** ![Carlos\_Teixeira](https://dub1.discourse-cdn.com/flex017/user_avatar/ask.lenses.io/carlos_teixeira/32/198_2.png) [@Carlos\_Teixeira](https://ask.lenses.io/u/Carlos_Teixeira)\
**Post date:** [July 30, 2025, 3:21pm UTC](https://ask.lenses.io/t/autocreatetopics-problems-in-k2k-kafka-replication-configuration-for-msk-serverless/406/5 "2025-07-30T15:21:55Z")

</div>

Hi James,

Thank you for trying K2K and going through the trouble of filling this report.  
My name is Carlos and I’m working directly on the K2K development.

So, in a nutshell, it seems like when using MSK, some topic properties are added that are non standard (`partition.size.max.bytes`).

Additionally it also seems like MSK does not allow updating some properties like `file.delete.delay.ms` .

The current way K2K works is that we use the Apache `KafkaAdminClient` and when we attempt to auto-create a topic, we simply read the topic’s properties from your source cluster and we attempt to create one with the same properties in the target.

It seems however that the `KafkaAdminClient` will happily read the non-standard properties but fails when attempting to apply them.

There are two possible workarounds at the moment:

- manually create the target cluster topic ahead of time
- repeat the process done before (setting `replication.common.config.”prop”` to **null** ) with all properties that are causing an issue . This should make these not be sent to the target cluster

In the meantime we’re actively working and iterating on K2K so we should have a way to better address this issue soon.