Hello Jun,
2. My original conclusion was incorrect. bootstrap.servers can support
NO_DEFAULT_VALUE with the validator
ConfigDef.ValidList.anyNonDuplicateValues(false, false). I propose updating the
KIP with the following changes:
1.ConsumerConfig – Change the default value of bootstrap.servers from List.of()
to NO_DEFAULT_VALUE.
2. ProducerConfig – Change the default value of bootstrap.servers from
List.of() to NO_DEFAULT_VALUE.
3. WorkerConfig – Change the default value of bootstrap.servers from
"localhost:9092" to NO_DEFAULT_VALUE
and deprecate the constant BOOTSTRAP_SERVERS_DEFAULT.
Best Regards,
Jiunn-Yang
> Jun Rao <j...@confluent.io.INVALID> 於 2025年8月12日 凌晨3:03 寫道：
>
> Hi, Jiunn-Yang,
>
> Thanks for the reply.
>
> 1 and 3. Sounds good.
>
> 2. Which bootstrap.servers are you referring to? Also, it's not clear to me
> why the validation fails since typically the validation happens when the
> config is initialized with the binding config file.
>
> Jun
>
> On Mon, Aug 11, 2025 at 6:38 AM 黃竣陽 <s7133...@gmail.com> wrote:
>
>> Hello all,
>>
>> I’ve started implementing this KIP, and there are a few configurations
>> that need further discussion:
>>
>> 1. HeaderFrom fields
>> This configuration should allow duplicate values. Therefore, its default
>> value
>> should be set to NO_DEFAULT_VALUE, and its validator should be
>> NonEmptyListValidator().
>> See the test case [1] for reference.
>>
>> 2. bootstrap.servers
>> If we set its default value to NO_DEFAULT_VALUE and use the validator
>> ConfigDef.ValidList.anyNonDuplicateValues(false, false),
>> initialization will fail because the default value does not pass the
>> validator. I see two possible solutions:
>>
>> Option 2.1: Set the default value to List.of("localhost:9092") (similar to
>> WorkerConfig) and use the validator
>> ConfigDef.ValidList.anyNonDuplicateValues(false, false). However, this
>> feels a bit odd, as the default value
>> should ideally be useful, and localhost:9092 is not meaningful for most
>> scenarios.
>>
>> Option 2.2: Keep the default value as NO_DEFAULT_VALUE and use
>> NonEmptyListValidator(). In this case,
>> we would need to move NonEmptyListValidator from the connect.transforms
>> module to the client module,
>> and make it a public API within ConfigDef. This would also align with how
>> most bootstrap.servers configs are handled.
>>
>> 3. Remove Cast fields config change
>> This configuration has its own validator, so we should leave it unchanged.
>>
>> [1]
>> https://github.com/apache/kafka/blob/18045c6ac30921503deffbef1744bb365dc599fb/connect/transforms/src/test/java/org/apache/kafka/connect/transforms/HeaderFromTest.java#L240
>>
>> Best Regards,
>> Jiunn-Yang
>>
>>> 黃竣陽 <s7133...@gmail.com> 於 2025年8月6日 晚上11:59 寫道：
>>>
>>> Hi Jun,
>>>
>>> Thanks for the reply,
>>>
>>> I have updated the KIP
>>>
>>> Best Regards,
>>> Jiunn-Yang
>>>
>>>> Jun Rao <j...@confluent.io.INVALID> 於 2025年8月6日 晚上11:34 寫道：
>>>>
>>>> Hi, Jiunn-Yang,
>>>>
>>>> Regarding bootstrap.servers in MirrorClientConfig, it's weird that it
>>>> defaults to an empty list while empty list is not allowed. It seems that
>>>> this should have no default value.
>>>>
>>>> Thanks,
>>>>
>>>> Jun
>>>>
>>>> On Wed, Aug 6, 2025 at 7:56 AM Chia-Ping Tsai <chia7...@gmail.com>
>> wrote:
>>>>
>>>>> Thanks to Jiunn-Yang for this hard KIP.
>>>>>
>>>>> It might not be perfect, but we can refine it during the PR review
>> process
>>>>> :)
>>>>>
>>>>>
>>>>> 黃竣陽 <s7133...@gmail.com> 於 2025年8月6日 週三 下午7:32寫道：
>>>>>
>>>>>> Hello chia,
>>>>>>
>>>>>> Thanks for the reply.
>>>>>>
>>>>>> chia05: I have updated the KIP to change the default values of
>>>>>> task.assigned.groups
>>>>>> and task.assigned.partitions from null to NO_DEFAULT_VALUE.
>>>>>>
>>>>>> chia06: I have also updated the KIP based on your feedback.
>>>>>>
>>>>>> Best Regards,
>>>>>> Jiunn-Yang
>>>>>>
>>>>>>> Chia-Ping Tsai <chia7...@gmail.com> 於 2025年8月6日 凌晨12:54 寫道：
>>>>>>>
>>>>>>> hi Jiunn-Yang
>>>>>>>
>>>>>>> chia05:
>>>>>>>
>>>>>>> `task.assigned.groups` and `task.assigned.partitions` should not have
>>>>>>> default value, right?
>>>>>>>
>>>>>>> chia06:
>>>>>>>
>>>>>>> `new HashSet<>(values).size()` -> `Set.copyOf(values).size()`
>>>>>>>
>>>>>>> Best,
>>>>>>> Chia-Ping
>>>>>>>
>>>>>>> Jun Rao <j...@confluent.io.invalid> 於 2025年8月5日 週二 下午11:39寫道：
>>>>>>>
>>>>>>>> Hi, Jiunn-Yang,
>>>>>>>>
>>>>>>>> Thanks for the reply and your patience. The KIP looks good to me
>> now.
>>>>>>>>
>>>>>>>> Hi, Luke, Mickael,
>>>>>>>>
>>>>>>>> Could you take a look at the KIP again and see if it makes sense to
>>>>> you?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Jun
>>>>>>>>
>>>>>>>> On Tue, Aug 5, 2025 at 3:04 AM 黃竣陽 <s7133...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hello Jun,
>>>>>>>>>
>>>>>>>>> Thanks for the reply,
>>>>>>>>>
>>>>>>>>> JR46: I have clarified the behavior for null and empty values, so
>>>>> users
>>>>>>>>> can
>>>>>>>>> understand the reasoning behind disallowing empty lists.
>>>>>>>>>
>>>>>>>>> JR48: I've updated the KIP accordingly.
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>> Jiunn-Yang
>>>>>>>>>
>>>>>>>>>> Jun Rao <j...@confluent.io.INVALID> 於 2025年8月5日 凌晨12:45 寫道：
>>>>>>>>>>
>>>>>>>>>> Hi, Jiunn-Yang,
>>>>>>>>>>
>>>>>>>>>> Thanks for the reply.
>>>>>>>>>>
>>>>>>>>>> JR46. "Currently, if plugin.path is set to an empty list, no
>>>>>>>>> user-specified
>>>>>>>>>> plugin locations are processed, but plugins from the parent
>>>>>> classloader
>>>>>>>>> are
>>>>>>>>>> still loaded." Could you add why the current behavior is bad for
>> the
>>>>>>>>> users?
>>>>>>>>>>
>>>>>>>>>> JR48. If we want to preserve the current behavior, we should
>> remove
>>>>>> the
>>>>>>>>>> following validation, right?
>>>>>>>>>> if (validStrings.length == 0) {
>>>>>>>>>> throw new IllegalArgumentException("Valid strings list
>>>>>>>> cannot
>>>>>>>>>> be empty for in validator");
>>>>>>>>>>
>>>>>>>>>> Jun
>>>>>>>>>>
>>>>>>>>>> On Fri, Aug 1, 2025 at 6:47 PM 黃竣陽 <s7133...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hello Jun,
>>>>>>>>>>>
>>>>>>>>>>> Thanks for the reply.
>>>>>>>>>>>
>>>>>>>>>>> JR42, JR45, JR46, JR47: I have updated the KIP.
>>>>>>>>>>>
>>>>>>>>>>> JR43: If bootstrap.servers is empty for these configurations,
>>>>>>>>>>> it will fail when creating the AdminClient. I have updated the
>> KIP
>>>>> to
>>>>>>>>>>> reflect this behavior.
>>>>>>>>>>>
>>>>>>>>>>> JR44: Thanks for pointing this out. Kafka will indeed fail at the
>>>>>>>>> storage
>>>>>>>>>>> format phase
>>>>>>>>>>> if the configuration is invalid. I have updated the KIP
>>>>> accordingly.
>>>>>>>>>>>
>>>>>>>>>>> JR48: The current in() method allows empty lists by default, so I
>>>>>>>>> believe
>>>>>>>>>>> setting isEmptyAllowed to true
>>>>>>>>>>> better preserves the original behavior. Therefore, I prefer not
>> to
>>>>>>>>> change
>>>>>>>>>>> this default.
>>>>>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>> Jiunn-Yang
>>>>>>>>>>>
>>>>>>>>>>>> Jun Rao <j...@confluent.io.INVALID> 於 2025年8月2日 凌晨2:38 寫道：
>>>>>>>>>>>>
>>>>>>>>>>>> Hi, Jiunn-Yang,
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for the reply. A few more comments.
>>>>>>>>>>>>
>>>>>>>>>>>> JR42. [6] [7] are not needed since currently an empty list
>> already
>>>>>>>>> causes
>>>>>>>>>>>> an exception.
>>>>>>>>>>>>
>>>>>>>>>>>> JR43. Could you document the current behavior when
>>>>> bootstrap.servers
>>>>>>>> is
>>>>>>>>>>>> empty in MirrorClientConfig and WorkerConfig?
>>>>>>>>>>>>
>>>>>>>>>>>> JR44. [12] seems incorrect. I set log.dir, but left log.dirs
>> empty
>>>>>>>> and
>>>>>>>>>>> got
>>>>>>>>>>>> the following.
>>>>>>>>>>>> bin/kafka-storage.sh format --standalone -t $KAFKA_CLUSTER_ID -c
>>>>>>>>>>>> config/server.properties
>>>>>>>>>>>> Exception in thread "main" java.lang.IllegalArgumentException:
>>>>>>>>>>> requirement
>>>>>>>>>>>> failed: At least one log directory must be defined via log.dirs
>> or
>>>>>>>>>>> log.dir.
>>>>>>>>>>>>
>>>>>>>>>>>> bin/kafka-server-start.sh config/server.properties
>>>>>>>>>>>> [2025-08-01 11:31:20,097] INFO Registered
>>>>>>>>>>>> `kafka:type=kafka.Log4jController` MBean
>>>>>>>>>>>> (kafka.utils.Log4jControllerRegistration$)
>>>>>>>>>>>> [2025-08-01 11:31:20,238] ERROR Exiting Kafka due to fatal
>>>>> exception
>>>>>>>>>>>> (kafka.Kafka$)
>>>>>>>>>>>> java.lang.IllegalArgumentException: requirement failed: At least
>>>>> one
>>>>>>>>> log
>>>>>>>>>>>> directory must be defined via log.dirs or log.dir.
>>>>>>>>>>>>
>>>>>>>>>>>> JR45. Could you group all configs for WorkerConfig together?
>>>>>>>>>>>>
>>>>>>>>>>>> JR46. plugin.path: We have the following code. So, currently, it
>>>>>>>> seems
>>>>>>>>>>> that
>>>>>>>>>>>> an empty list is allowed for plugin.path and we treat it by
>> adding
>>>>>>>> the
>>>>>>>>>>>> parent path of the classloader. It would be useful to justify
>> why
>>>>>>>>>>>> disallowing empty is better for the users.
>>>>>>>>>>>>
>>>>>>>>>>>> public static Set<PluginSource> pluginSources(Set<Path>
>>>>>>>>>>>> pluginLocations, ClassLoader classLoader,
>> PluginClassLoaderFactory
>>>>>>>>>>> factory)
>>>>>>>>>>>> {
>>>>>>>>>>>> Set<PluginSource> pluginSources = new LinkedHashSet<>();
>>>>>>>>>>>> for (Path pluginLocation : pluginLocations) {
>>>>>>>>>>>> try {
>>>>>>>>>>>>
>>>>> pluginSources.add(isolatedPluginSource(pluginLocation,
>>>>>>>>>>>> classLoader, factory));
>>>>>>>>>>>> } catch (InvalidPathException | MalformedURLException e)
>>>>> {
>>>>>>>>>>>> log.error("Invalid path in plugin path: {}.
>>>>> Ignoring.",
>>>>>>>>>>>> pluginLocation, e);
>>>>>>>>>>>> } catch (IOException e) {
>>>>>>>>>>>> log.error("Could not get listing for plugin path: {}.
>>>>>>>>>>>> Ignoring.", pluginLocation, e);
>>>>>>>>>>>> }
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>> pluginSources.add(classpathPluginSource(classLoader.getParent()));
>>>>>>>>>>>> return pluginSources;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> JR47. typo in "Should not allow setting validStrings is empty"
>>>>>>>>>>>>
>>>>>>>>>>>> JR48. We should pass in isEmptyAllowed as false in the code
>> below,
>>>>>>>>> right?
>>>>>>>>>>>> public static ValidList in(String... validStrings) {
>>>>>>>>>>>> if (validStrings.length == 0) {
>>>>>>>>>>>> throw new IllegalArgumentException("Valid strings list
>>>>>>>> cannot
>>>>>>>>>>>> be empty for in validator");
>>>>>>>>>>>> }
>>>>>>>>>>>> return new ValidList(List.of(validStrings), true, false);
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> Jun
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Jul 29, 2025 at 8:53 AM 黃竣陽 <s7133...@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hello Jun,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sorry for the late reply,
>>>>>>>>>>>>>
>>>>>>>>>>>>> JR40, JR41: I have updated the KIP based on your comments.
>> Please
>>>>>>>>> take a
>>>>>>>>>>>>> look.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>> Jiunn-Yang
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jun Rao <j...@confluent.io.INVALID> 於 2025年7月24日 凌晨2:56 寫道：
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi, Jiunn-Yang,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks for the reply.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> JR40. In the table, there are a few configs for which we now
>>>>>>>> disallow
>>>>>>>>>>>>> empty
>>>>>>>>>>>>>> lists. It would be useful to document the current behavior for
>>>>>> each
>>>>>>>>> of
>>>>>>>>>>>>> them
>>>>>>>>>>>>>> more accurately. It seems that they should all lead to some
>> bad
>>>>>>>>>>> behavior.
>>>>>>>>>>>>>> For example, if log.dirs is empty, it seems that we can't
>> create
>>>>>>>>>>> topics?
>>>>>>>>>>>>>> If group.coordinator.rebalance.protocols is empty, the group
>>>>>>>>> rebalance
>>>>>>>>>>>>>> protocol will fail?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> JR41. It would be useful to clean up the "Compatibility,
>>>>>>>> Deprecation,
>>>>>>>>>>> and
>>>>>>>>>>>>>> Migration Plan" section a bit.
>>>>>>>>>>>>>> JR41.1 The migration plan has "Introduce a new properties
>>>>>>>>>>> isEmptyAllowed
>>>>>>>>>>>>> ,
>>>>>>>>>>>>>> isNullAllowed", which needs to be changed.
>>>>>>>>>>>>>> JR41.2 It started with "For users who configure an empty
>> list",
>>>>>> but
>>>>>>>>> not
>>>>>>>>>>>>> all
>>>>>>>>>>>>>> the bullet points are about empty lists.
>>>>>>>>>>>>>> JR41.3 To me, it would be useful to summarize why the behavior
>>>>>>>>> changes
>>>>>>>>>>>>> are
>>>>>>>>>>>>>> justified. We made 3 types of changes. (1) Disallow null. This
>>>>> is
>>>>>>>> ok
>>>>>>>>>>>>> since
>>>>>>>>>>>>>> one can't really set a null value through a config file. (2)
>>>>>>>> Disallow
>>>>>>>>>>>>>> duplicates. This is ok since it's rare and confusing. (3)
>>>>> Disallow
>>>>>>>>>>> empty.
>>>>>>>>>>>>>> Ideally, we want to claim that for those cases, they all lead
>> to
>>>>>>>> some
>>>>>>>>>>>>> other
>>>>>>>>>>>>>> errors or had behavior currently.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jun
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Jul 23, 2025 at 4:42 AM 黃竣陽 <s7133...@gmail.com>
>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hello Jun,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks for the reply.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> JR34 ,JR36, JR39: I’ve updated the KIP to reflect these
>>>>> changes.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> JR38: I clarified the following configurations:
>>>>>>>>>>>>>>> early.start.listeners: This config is optional and allows
>> both
>>>>>>>> null
>>>>>>>>>>> and
>>>>>>>>>>>>>>> empty lists.
>>>>>>>>>>>>>>> log.dirs and plugin.path: These are also optional, but only
>>>>> allow
>>>>>>>>>>>>>>> null—empty lists are not permitted.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>> Jiunn-Yang
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Jun Rao <j...@confluent.io.INVALID> 於 2025年7月23日 凌晨2:28 寫道：
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi, Jiunn-Yang and Chia-Ping,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks for the reply.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> JR34. Sounds good.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> JR36. Could you document that the default value for
>>>>>>>>>>>>>>>> sasl.oauthbearer.expected.audience and ssl.cipher.suites
>> have
>>>>>>>> been
>>>>>>>>>>>>>>> changed?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> JR38. My concern wasn't quite addressed. "If the
>> configuration
>>>>>> is
>>>>>>>>>>>>>>> optional,
>>>>>>>>>>>>>>>> we will reject any duplicate values in the list." This
>> implies
>>>>>>>> that
>>>>>>>>>>> if
>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>> config is optional, we allow empty lists. However, for
>>>>>>>> plugin.path,
>>>>>>>>>>> we
>>>>>>>>>>>>>>>> reject empty lists.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> JR39. We can remove the fields isEmptyAllowed and
>>>>> isNullAllowed
>>>>>>>>> since
>>>>>>>>>>>>>>> they
>>>>>>>>>>>>>>>> are not public facing.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Jun
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Tue, Jul 22, 2025 at 4:26 AM 黃竣陽 <s7133...@gmail.com>
>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hello Jun, Chia,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks for the reply,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> JR36: I’ve updated the following configurations:
>>>>>>>>>>>>>>>>> - sasl.oauthbearer.expected.audience
>>>>>>>>>>>>>>>>> - ssl.cipher.suites
>>>>>>>>>>>>>>>>> - ssl.enabled.protocols
>>>>>>>>>>>>>>>>> These now allow both empty and non-empty lists. Since the
>>>>>>>> default
>>>>>>>>>>>>> values
>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>> sasl.oauthbearer.expected.audience and ssl.cipher.suites
>> were
>>>>>>>>>>>>> previously
>>>>>>>>>>>>>>>>> null,
>>>>>>>>>>>>>>>>> I’ve updated their defaults to List.of() for consistency.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> JR37: A ClassCastException does not occur in
>>>>> MirrorClientConfig
>>>>>>>>> and
>>>>>>>>>>> it
>>>>>>>>>>>>>>>>> should be none.
>>>>>>>>>>>>>>>>> I’ve updated this in the KIP.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> JR38 & JR40: I’ve added a note below the table to indicate
>>>>>> which
>>>>>>>>>>>>>>>>> configurations require special attention.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> JR39: Yes, these properties are package-private.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>> Jiunn-Yang
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Chia-Ping Tsai <chia7...@gmail.com> 於 2025年7月22日 下午6:04
>> 寫道：
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> JR34. Hmm, it seems that the code in taskConfigs() could
>>>>>> return
>>>>>>>>> an
>>>>>>>>>>>>>>> empty
>>>>>>>>>>>>>>>>>> list for a task if knownSourceTopicPartitions is less than
>>>>>>>>>>> maxTasks,
>>>>>>>>>>>>>>>>>> Chia-Ping?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Yes, `MirrorSourceConnector#taskConfigs` could return an
>>>>> empty
>>>>>>>>>>> list,
>>>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>>>>> means no `MirrorSourceTask` can be created.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> By contrast, if any `MirrorSourceTask` is created, the
>>>>> configs
>>>>>>>>> used
>>>>>>>>>>>>> by
>>>>>>>>>>>>>>>>>> `MirrorSourceTask` must contain `task.assigned.partitions`
>>>>>>>> with a
>>>>>>>>>>>>>>>>> non-empty
>>>>>>>>>>>>>>>>>> value.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Jun Rao <j...@confluent.io.invalid> 於 2025年7月22日 週二
>>>>> 上午5:14寫道：
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hi, Jiunn-Yang and Chia-Ping,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks for the reply.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> JR34. Hmm, it seems that the code in taskConfigs() could
>>>>>>>> return
>>>>>>>>> an
>>>>>>>>>>>>>>> empty
>>>>>>>>>>>>>>>>>>> list for a task if knownSourceTopicPartitions is less
>> than
>>>>>>>>>>> maxTasks,
>>>>>>>>>>>>>>>>>>> Chia-Ping?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> JR36. Sounds good. Could you update the KIP? Also, should
>>>>> we
>>>>>>>> do
>>>>>>>>>>> the
>>>>>>>>>>>>>>> same
>>>>>>>>>>>>>>>>>>> for ssl.cipher.suites and
>>>>> sasl.oauthbearer.expected.audience?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> JR37. Is it true that
>> MirrorClientConfig.bootstrap.servers
>>>>>>>>> returns
>>>>>>>>>>>>>>>>>>> ClassCastException for null? It seems that null could be
>>>>>>>> casted
>>>>>>>>> to
>>>>>>>>>>>>> any
>>>>>>>>>>>>>>>>>>> class.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> JR38. "If the configuration is optional, we will reject
>> any
>>>>>>>>>>>>> duplicate
>>>>>>>>>>>>>>>>>>> values in the list." Could you clarify this? For example,
>>>>>>>>>>>>> plugin.path
>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>> optional, but with a default value. We reject duplicates
>> as
>>>>>>>> well
>>>>>>>>>>> as
>>>>>>>>>>>>>>>>> empty
>>>>>>>>>>>>>>>>>>> lists.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> JR39. isEmptyAllowed and isNullAllowed are not public
>>>>> fields,
>>>>>>>>>>> right?
>>>>>>>>>>>>>>>>> They
>>>>>>>>>>>>>>>>>>> are only public in the anyNonDuplicateValues() method.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> JR40. It would be useful to mention that if
>> cleanup.policy
>>>>> is
>>>>>>>>>>> empty
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> remote.storage.enable is true, the local log segments
>> will
>>>>> be
>>>>>>>>>>>>> cleaned
>>>>>>>>>>>>>>>>> based
>>>>>>>>>>>>>>>>>>> on log.local.retention.bytes and log.local.retention.ms.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Jun
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Fri, Jul 18, 2025 at 9:52 AM Chia-Ping Tsai <
>>>>>>>>>>> chia7...@gmail.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> JR34: For these two configurations, setting an empty
>> list
>>>>>>>>> feels
>>>>>>>>>>> a
>>>>>>>>>>>>>>> bit
>>>>>>>>>>>>>>>>>>>>> unintuitive. If an empty list is
>>>>>>>>>>>>>>>>>>>>> provided, the consumer will call the unsubscribe
>> method,
>>>>>>>> which
>>>>>>>>>>>>>>> doesn't
>>>>>>>>>>>>>>>>>>>>> seem appropriate given
>>>>>>>>>>>>>>>>>>>>> the documentation states: "Topic-partitions assigned to
>>>>>> this
>>>>>>>>>>> task
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> replicate."
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> agreed. Additionally, the source code [0] shows that it
>> is
>>>>>>>> not
>>>>>>>>>>>>>>> intended
>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> generate empty tps for the source task
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> [0]
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>> https://github.com/apache/kafka/blob/9b542b6ea21e84677a9292f250fc25f8b4162e6f/connect/mirror/src/main/java/org/apache/kafka/connect/mirror/MirrorSourceConnector.java#L202
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>
>>
