Hi, Fede, Thanks for the reply. A few more comments.
JR31.3 "Regarding state caching: the mirror partition cache lives in MirrorMetadataManager. It is populated in two ways: by replaying __mirror_state partitions this broker leads, and by fetching state from remote coordinators via ReadMirrorStates RPCs." Hmm, a given broker only caches the mirror partition state for partitions hashed into the __mirror_state partition hosted on this broker, right? Why does it need to fetch the state from other remote coordinators? JR36. I am still not quite sure why we need MirrorLeaderEpoch in the Fetch request. In the current Fetch request, in addition to CurrentLeaderEpoch, it has another field LastFetchedEpoch, which captures the last leader epoch in the data and is used to resolve the inconsistency between the follower and the leader. Does it achieve the same purpose as MirrorLeaderEpoch? JR48. "The NumPartitions field is needed so the controller can create the destination topic if it does not already exist. When a topic is being mirrored for the first time, the destination cluster has no knowledge of the source topic's partition count, so the request must carry it." Hmm, this seems inconsistent. When a mirror is started, the source topic may not exist yet. When the source topic is created later, we can start mirroring without requiring the user to provide the number of partitions. JR51. Start Mirror: I am wondering if we truly need the last mirror epoch for truncation when starting a mirror. When a mirror is stopped at the source, we already bump up the leader epoch and write some additional records for cleanup. It seems that we can just use the DivergingEpoch returned in the initial mirror Fetch request to detect the diverging epoch and use that for truncation at the mirror destination. JR52. Stop Mirror: JR52.1 "3. If patterns are provided, the controller removes matching entries from mirror.topics.include or adds them to mirror.topics.exclude on the CLUSTER_MIRROR resource." Why is it 'or' and not 'and'? JR52.2 "7. On subsequent metadata refresh cycles, MirrorMetadataManager discovers new source topics matching the persisted include/exclude patterns and repeats steps 3 through 7 for each." The broker will send a create topic request to the controller. How does the controller associate it with the mirror name to create a `MirrorTopicStateChangeRecord`? JR53. Describe Mirrors: JR53.1 "1. The user sends a DescribeClusterMirrors request with optional mirror names (empty means all mirrors)." In metadata request, we use a null arrary to represent all topics. It would be useful to be consistent here. JR53.2 "2. The admin client fans out the request to all brokers and merges the responses client-side." This is not ideal. Not every broker hosts a mirror partition. So sending the request to every broker is wasteful. It's probably better to send the request to a single broker, which can then contact the right MirrorFetcherManager and ClusterMirrorCoordinator. JR54. MirrorTopicStateChangeRecord.DesiredState: Are MIRRORING, PAUSED, STOPPED the only validate states? The state table has other states too. Ditto for MirrorPartitionState. Jun On Fri, Jul 31, 2026 at 7:52 AM Federico Valeri <[email protected]> wrote: > Hi Andrew, yes, validation is called at the start of createTopic. If > the topic ID is invalid, the request fails with INVALID_REQUEST. If > the topic ID is already used by a different topic name, it fails with > TOPIC_ALREADY_EXISTS. In both cases, only the individual topic in the > batch fails; other topics in the same CreateTopics request continue > processing normally. Added this information to the KIP. > > > > On Fri, Jul 31, 2026 at 10:53 AM Andrew Schofield <[email protected]> > wrote: > > > > Hi Fede, > > One more small question. > > > > AS37: If the controller fails validation for the MirrorInfo.TopicId > added to the CreateTopic request, what does it do? I suspect that it fails > the request with a particular error code. > > > > Thanks, > > Andrew > > > > On 2026/07/30 17:13:46 Federico Valeri wrote: > > > Hi all, > > > > > > We updated the KIP to include Coordinator Runtime configurations and > > > the coordinator state transition validation paragraph. The latter > > > covers the per-partition epoch fencing mechanism (leader epoch and > > > state epoch) that complements the existing per-topic StateOffset > > > fencing for lifecycle operations. > > > > > > Thanks, > > > Fede > > > >
