Repository navigation
[fix][broker] Derive scalable topic identity from the raw local name - #26668
Merged
nodece merged 1 commit intoSep 21, 2026
Merged
Conversation
nodece
approved these changes
Sep 21, 2026
TimurRakhmatullin86
force-pushed
the
fix/to-scalable-topic-local-name
branch
from
September 21, 2026 04:02
768c9be to
b1c4266
Compare
TimurRakhmatullin86
changed the title
TopicName#toScalableTopic() built the topic:// identity from the URL-encoded local name, but topic name parsing never URL-decodes. For any local name containing a character that Codec.encode rewrites (space, '+', '%', non-ASCII, ...), the derived identity differed from the same topic spelled directly in the topic:// domain: - persistent://t/ns/a b resolved to topic://t/ns/a+b, colliding with a topic literally named "a+b" and diverging from topic://t/ns/a b. - Consumers of the result encode again when building metadata paths (ScalableTopicResources#topicPath), so lookups went to .../a%2Bb while the record created for the topic lives under .../a+b. The PIP-475 check in BrokerService#isAllowAutoTopicCreationAsync then misses the scalable topic record and would allow recreating a migrated persistent topic that the migration is supposed to shadow-protect. Splice the local name verbatim, matching SegmentTopicName and the rest of TopicName, which apply Codec.encode only when serializing to REST or metadata paths.
nodece
changed the title
1 task done
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
3 participants
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.
Motivation
TopicName.toScalableTopic()builds thetopic://identity frombase.getEncodedLocalName(), which URL-encodes the local name viaCodec.encode. ButTopicNameparsing never URL-decodes local names — the constructor stores the name verbatim. So for any local name containing a characterURLEncoderrewrites (a space,+,%, a non-ASCII character…), the derived scalable identity is a different topic than the same topic addressed directly in thetopic://domain, and it can collide with a topic literally named after the encoded form.For example:
TopicName.get("persistent://t/ns/a b").toScalableTopic()yieldstopic://t/ns/a+b(local namea+b), nottopic://t/ns/a b— two identities for one topic, and a collision with a topic literally nameda+b.%is double-encoded on the next round trip:x%20ybecomesx%2520y.Everywhere else
getEncodedLocalName()is used only when serializing to a REST or metadata path; identities are otherwise spliced from the raw local name.Modifications
Splice the raw local name (
base.getLocalName()) instead of the encoded one, so the derived scalable topic round-trips throughTopicNameparsing and matches the same topic addressed directly. Added a short Javadoc note on why encoding must not be applied here.Added
TopicNameTest#testToScalableTopicPreservesLocalName, which asserts that the local name is preserved, both spellings resolve to the same identity, there is no collision with a literally-+name, a%is not re-encoded, and partition stripping keeps the verbatim name.Verifying this change
This change is covered by the added unit test
TopicNameTest#testToScalableTopicPreservesLocalName. It fails without the fix (expected [a b] but found [a+b]) and passes with it. No existing test changes behavior, because existing tests use plain names for whichCodec.encodeis the identity.Found by code inspection; there is no pre-existing issue.
Does this pull request potentially affect one of the following parts:
Documentation
doc-not-needed