kafka: validate sink config against existing topics#5715
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Warning Review limit reached
Next review available in: 7 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthroughKafka sink verification now validates existing topics through encoder construction, creates missing topics conditionally, and uses topic replication metadata when validating ChangesKafka sink validation
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant Verify
participant AdminClient
participant verifyKafkaSink
participant EventEncoder
Verify->>AdminClient: create admin client
Verify->>verifyKafkaSink: pass topic and encoder configuration
verifyKafkaSink->>AdminClient: fetch topic metadata
verifyKafkaSink->>AdminClient: create missing topic when AutoCreate is enabled
verifyKafkaSink->>EventEncoder: construct encoder and validate claim-check storage
Possibly related PRs
Suggested labels: Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
/test all |
|
/test all |
|
/test all |
|
/retest |
|
@3AceShowHand: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
What problem does this PR solve?
Kafka sink verification creates the claim-check instance before checking topic metadata, but it initializes the event encoder only after the missing-topic branch. If the topic already exists, verification returns before encoder initialization and can miss errors such as an unavailable Avro Schema Registry.
The
required-acks=allcheck also uses the configuredreplication-factorinstead of the existing topic's actual replication factor.Issue Number: close #5720
What is changed and how it works?
Verify; no separateverifyKafkaSinkhelper is needed.min.insync.replicasagainst the actual replication factor for existing topics.Check List
Tests
Unit test
Questions
Will it cause performance regression or break compatibility?
No compatibility changes. Existing-topic verification now initializes the encoder and checks its dependencies. For Avro, this includes the expected Schema Registry connectivity check during verification.
Do you need to update user documentation, design documentation or monitoring documentation?
No. This fixes verification behavior without changing user-facing configuration or monitoring.
Release note