feat: validate topicNameTemplate with context variable resolution#71
Open
yannrouillard wants to merge 6 commits into
Open
feat: validate topicNameTemplate with context variable resolution#71yannrouillard wants to merge 6 commits into
yannrouillard wants to merge 6 commits into
Conversation
Kafka Streams changelog and repartition topics use
{applicationId}-{name}-(changelog|repartition) naming which doesn't
follow the serviceName.dataIdentifier convention. Allow these through.
…me prefix
Prevent copy-paste mistakes where an internal topic is reused across
service instances by checking that changelog/repartition topics start
with {serviceName}-{instanceName}-, matching the Kafka Streams applicationId
convention.
Replace PR version 0.1.157-pr195 with stable 0.1.224 (base) and 0.1.225 (dev override), which are the latest stable releases and include the maxLocalTopicBytesCompliance custom validator support. This also properly demonstrates the env-specific chart loading feature with two distinct stable versions.
- Version suffix: (-[0-9]+)? → (-v[0-9]+)? to require the v prefix (e.g. -v1) - Instance suffix: (\.[a-z0-9]+)? → (\.[a-z0-9-]+)? to allow hyphens (e.g. .mirrored-prod)
…omment - Delete unused service2 Kafka Streams test data files (leftover from before the prefix check was introduced; would have failed if tested) - Add test + data for internal topic from a foreign service (wrong serviceName prefix, not just wrong instance) - Add tests + data pinning the TOPIC_NAME_REGEXP changes: -vN suffix and hyphenated suffix are now accepted - Clarify TOPIC_NAME_REGEXP comment: format validation is the schema's responsibility; the regexp only enforces service name ownership
Extend validate_topic_name_compliance to handle topicNameTemplate fields. When validating a template, known context variables (serviceName, instanceName, serviceInstanceName, env) are resolved to their actual values before checking the topic name structure. This enables using $.context.serviceInstanceName in changelog/repartition topics while still verifying the serviceName-instanceName prefix is correct.
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
2 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.
Summary
validate_topic_name_complianceto handletopicNameTemplatefields by detecting the field type via the JSON Schema path tracker_resolve_topic_name_template()which replaces known context variables (serviceName,instanceName,serviceInstanceName,env) with their actual values, then validates the resolved topic name against the same rules as statictopicName{{ $.context.serviceInstanceName }}-store-changelogwhile still verifying theserviceName-instanceNameprefix is correctCompanion PR: Kpler/platform-managed-chart — relaxes the
topicNameTemplateregex for internal topics.Test plan