-
Notifications
You must be signed in to change notification settings - Fork 339
feat: allow null and empty headers configuration option #865
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
feat: allow null and empty headers configuration option #865
Conversation
|
🎉 All Contributor License Agreements have been signed. Ready to merge. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR adds a new configuration option to allow the S3 Sink Connector to process messages with null or empty headers when header writing is enabled. Previously, the connector would throw an error when encountering messages without headers even if header writing was configured.
- Adds
allow.null.and.empty.headersconfiguration option with default valuefalse - Modifies header validation logic to skip the error when the new option is enabled
- Includes unit test to verify the new behavior works correctly
Reviewed Changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| S3SinkConnectorConfig.java | Adds new configuration option definition and accessor method |
| KeyValueHeaderRecordWriterProvider.java | Updates header validation logic to check the new configuration |
| S3SinkTaskTest.java | Adds unit test for the new null/empty headers functionality |
kafka-connect-s3/src/main/java/io/confluent/connect/s3/S3SinkConnectorConfig.java
Outdated
Show resolved
Hide resolved
|
@subhashiyer9 Sorry to bother - any chance I could get some feedback on this change please? |
Problem
S3 Sink Connector will throw an error when processing a message with missing/empty headers when write headers is enabled.
In certain cases, users may wish to process topics that have a mix of messages with and without headers, and to save the headers where they exist.
For example:
#602
Solution
Provide a configuration option to allowmessages with missing headers, even when write headers is enabled.
The expected behaviour is that the connector will simply not write the header if it is empty or missing.
The default behaviour state of the setting will be
false, to maintain current behaviour of throwing an exception.Does this solution apply anywhere else?
Test Strategy
Manual testing on developer device.
Testing done:
Release Plan