hi Gaurav I'm still trying to understand the necessity. The "short" type is a kind of spec, so I don't think we will make breaking change to it.
Best, Chia-Ping Gaurav Narula <[email protected]> 於 2026年7月18日週六 下午8:33寫道： > Hi Matthias, > > Thank you for your reply. > > Consider a scenario where a KIP author wants to propose a change which > involves > new Request/Response types and a new Metadata Record type. As you rightly > mentioned, the author doesn't need to pick specific values in the KIP but > if > they are to prototype their work in their fork they do need to pick one. > > This is where the prototyper has to make a careful choice. If they pick > the next > available apiKey, they run the risk of running into issues when the value > they > picked is claimed by another implementation that's merged first upstream, > specially when the prototype is deployed. Even if they bump the apiKey > after a > rebase, safely rolling out changes in such a scenario would be hard as > existing > brokers/controllers would have a different mapping for the apiKeys > compared to > the new ones. > > A workaround for this is selecting a high enough apiKey value that is > unlikely > to be used in the foreseeable future. My proposal formalises that to > reserve > some values for private use. This also ensures that future KIPs that > propose any > changes to how apiKeys are used take that into account. > > Regards, > Gaurav > > > > On 17 Jul 2026, at 21:25, Matthias J. Sax <[email protected]> wrote: > > > > Hello Gaurav, > > > > I am not sure if I fully understand the motivation of the KIP. You are > saying > > > >> However, contributors run the risk of adopting an apKey that is > subsequently claimed by another proposal while they prototype their work. > > > > Can you elaborate? Sure, if two KIPs are in-flight in parallel, two KIPs > might not know the available API keys yet, but PRs are merged one after > each other, and whoever comes last would update the code and KIP > accordingly. Most KIPs don't even specify the concrete API key number to > begin with, as it's subject to "availability" when the corresponding PR > gets merged. > > > > This approach did work in the past, so I am not sure if there is an > actual problem to be solved, which would require your proposal? Maybe I am > missing something. > > > > -Matthias > > > > > > -----Original Message----- > > From: Gaurav Narula <[email protected] <mailto:[email protected]>> > > Reply-To: <[email protected] <mailto:[email protected]>> > > Date: Thursday, July 16, 2026 at 8:39 AM > > To: <[email protected] <mailto:[email protected]>> > > Subject: [DISCUSS] KIP-1367: Reserve apiKey values for private use > > > > > > Hi Everyone! > > > > > > I’d like to start a discussion on a KIP for reserving apiKey values for > private use. > > > > > > More details at: > https://cwiki.apache.org/confluence/spaces/KAFKA/pages/440304597/KIP-1367+Reserve+apiKey+values+for+private+use > < > https://cwiki.apache.org/confluence/spaces/KAFKA/pages/440304597/KIP-1367+Reserve+apiKey+values+for+private+use > > > > > > > > Looking forward to your comments! > > > > > > Regards, > > Gaurav Narula > > > > > >
