Hi Andrew, Thanks for the KIP. I agree we should tighten the rules for the protocol to limit the complexity and size of requests and responses.
LC1: From the table, I think we also need to add: 1. IncrementalAlterConfigsRequest 2. AlterConfigsRequest because we allow users to add/update any config name/value to the broker. LC2: In AlterReplicaLogDirsRequest, we allow users to set the path, should we also limit it? LC3: In AlterUserScramCredentialsRequest, we allow users to set a random scram name. I'm thinking if we should directly limit all String fields to size 249 directly? And consider loosening or tightening the rule for specific fields, like "Group member ID" and "Offset commit metadata"? Thank you, Luke On Tue, Nov 25, 2025 at 9:49 AM Kirk True <[email protected]> wrote: > Hi Andrew, > > As proposed, I don't think there's a straightforward way to log warnings > that won't require knowledge of the broker's enforcement status. > Ultimately, the cluster administrators have the option of setting > resource.identifier.limit.enable back to false in a "break glass" situation. > > Thanks, > Kirk > > On Tue, Nov 4, 2025, at 2:02 AM, Andrew Schofield wrote: > > Hi Kirk, > > Thanks for reviewing the KIP. > > > > KT1: I suppose one way would be to issue a warning log in the client if > the user attempts to use identifiers longer than the KIP recommends. We > could even make it conditional on the version of the requests being built > so that the “proper” exception is thrown instead if the broker supports the > bumped versions of the APIs which support the new error code. I don’t think > we should pander too much to these people. Wdyt? > > > > Thanks, > > Andrew > > > > > On 4 Nov 2025, at 01:36, Kirk True <[email protected]> wrote: > > > > > > Hi Andrew, > > > > > > Thanks for the KIP. I like the idea of standardizing the resource ID > lengths and largely agree that—to paraphrase an apocryphal quote—no one > will ever need more than 249 characters. > > > > > > KT1: My understanding is that the client will be ignorant of the > limits, up until the point the server returns the > "RESOURCE_IDENTIFIER_TOO_LARGE" error. I worry that for (the small number > of) users whose IDs violate these limits, their applications will work one > day, and then unexpectedly break the next. Ideally there would be a grace > period in which to warn users that they're over the limits so they can make > changes before the limits are enforced. Warning logs could be added on the > broker side, but that information may not make it to an organization's > individual applications because it's not always easy to correlate the > warnings to a particular application. > > > > > > Thanks, > > > Kirk > > > > > > On Sun, Nov 2, 2025, at 4:22 AM, Andrew Schofield wrote: > > >> Hi, > > >> I’d like to start discussion on KIP-1233: Maximum lengths for > resource names and IDs. > > >> > > >> Today, Kafka applies a limit of 249 characters for topic names, but > other identifiers such > > >> as group IDs do not have limits. The KIP proposes introducing limits > for all resource > > >> names and identifiers in Apache Kafka 5.0. The proposed limits are > intended to be large > > >> enough that nobody is impacted. > > >> > > >> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1233%3A+Maximum+lengths+for+resource+names+and+IDs > > >> > > >> Thanks, > > >> Andrew > > >> > > > > >
