Hi Mayank, > On Jul 14, 2023, at 11:25 AM, Mayank Shekhar Narula > <mayanks.nar...@gmail.com> wrote: > > Kirk > > >> Is the requested restructuring of the response “simply” to preserve bytes, >> or is it possible that the fetch response could/should/would return >> leadership changes for partitions that we’re specifically requested? >> > > Moving endpoints to top-level fields would preserve bytes, otherwise the > endpoint-information would be duplicated if included with the > partition-data in the response. Right now, the top-level field will only be > set in case leader changes for any requested partitions. But it can be > re-used in the future, for which Jose has a use-case in mind shared up in > the thread. KIP is now upto date with endpoint info being at top-level.
I didn’t catch before that there was a separate section for the full node information, not just the ID and epoch. Thanks! >>> 3. In the future, I may use this information in the KRaft/Metadata >>> implementation of FETCH. In that implementation not all of the >>> replicas are brokers. >> >> Side point: any references to the change you’re referring to? The idea of >> non-brokers serving as replicas is blowing my mind a bit :) >> >> > Jose, I missed this as well, would love to know more about non-broker > serving as replica! > -- > Regards, > Mayank Shekhar Narula
