Hi Andrew, Thanks for the KIP.
The KIP says: If the client is bootstrapping, it does not supply ClusterId or NodeId . After bootstrapping, during which it learns the information from its initial Metadata response, it supplies both. It will be good to clarify the behaviour during re-bootstrapping. We clear the current metadata during re-bootstrap and revert to bootstrap metadata. At this point, we don't retain node ids or cluster id from previous metadata responses. I think this makes sense because we want re-bootstrapping to behave in the same way as the first bootstrap. If we retain this behaviour, validation of cluster id and node-id will be based on the Metadata response of the last bootstrap, which is not necessarily the initial Metadata response. I think this is the desired behaviour, can we clarify in the KIP? Kafka clients have always supported cluster id change without requiring restart. Do we need an opt-out in case some deployments rely on this feature? If re-bootstrapping is enabled, clients would re-bootstrap if connections consistently fail. So as long as we continue to clear old metadata on re-bootstrap, we should be fine. Not sure if we need an explicit opt-out for the case where re-bootstrapping is disabled. Thanks, Rajini On Thu, Feb 12, 2026 at 1:43 PM Andrew Schofield <[email protected]> wrote: > Hi David, > Thanks for your question. > > Here's one elderly JIRA I've unearthed which is related > https://issues.apache.org/jira/browse/KAFKA-15828. > > I am also aware of suspected problems in the networking for cloud > providers which occasionally seem to route connections to the wrong place. > > The KIP is aiming to get some basic diagnosis and recovery into the Kafka > protocol where today there is none. As you can imagine, there is total > mayhem when a client confidently thinks it's talking to one broker when > actually it's talking to quite another. Diagnosis of this kind of problem > would really help in getting to the bottom of rare issues such as these. > > Thanks, > Andrew > > On 2026/02/11 16:12:50 David Arthur wrote: > > Thanks for the KIP, Andrew. I'm all for making the client more robust > > against networking and deployment weirdness > > > > I'm not sure I fully grok the scenario you are covering here. It sounds > > like you're guarding against a hostname being reused by a different > broker. > > Does the client not learn about the new broker hostnames when it > refreshes > > metadata periodically? > > > > -David > > > > On Thu, Nov 20, 2025 at 5:59 AM Andrew Schofield < > [email protected]> > > wrote: > > > > > Hi, > > > I would like to start discussion of a new KIP for detecting and > handling > > > misrouted connections from Kafka clients. The Kafka protocol does not > > > contain any information for working out when the broker metadata > > > information in a client is inconsistent or stale. This KIP proposes a > way > > > to address this. > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1242%3A+Detection+and+handling+of+misrouted+connections > > > > > > Thanks, > > > Andrew > > > > > > > > > -- > > David Arthur > > >
