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 > >
