fix(kraft): generate canonical padding-free cluster ID - #305
Open
amuraru wants to merge 1 commit into
Open
Conversation
generateRandomClusterID used base64.URLEncoding, producing a 24-character padded id (e.g. "…=="). Kafka 3.9's Uuid.fromString happens to accept it (length <= 24 and its URL decoder tolerates padding), but that is a non-canonical form: Kafka itself emits the 22-character padding-free encoding via Base64.getUrlEncoder().withoutPadding(), and newer Kafka versions reject longer strings. Switch to base64.RawURLEncoding so freshly generated cluster IDs match Kafka's canonical form. Existing clusters are unaffected: their id is already persisted in KafkaCluster.Status.ClusterID and reused verbatim. Strengthen TestGenerateClusterID to assert the id decodes to exactly 16 bytes and is 22 characters long. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> (cherry picked from commit ed420fc)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Split out of #300 (1/6).
generateRandomClusterIDusedbase64.URLEncoding, producing a 24-characterpadded id (e.g. "...=="). Kafka 3.9's
Uuid.fromStringhappens to accept it(length <= 24 and its URL decoder tolerates padding), but that is a
non-canonical form: Kafka itself emits the 22-character padding-free
encoding via
Base64.getUrlEncoder().withoutPadding(), and newer Kafkaversions reject longer strings. Switch to
base64.RawURLEncodingso freshlygenerated cluster IDs match Kafka's canonical form.
Existing clusters are unaffected: their id is already persisted in
KafkaCluster.Status.ClusterIDand reused verbatim.Strengthens
TestGenerateClusterIDto assert the id decodes to exactly 16bytes and is 22 characters long.