KAFKA-20939: Disable async dns resolution in streams and connect - #23364
Open
frankvicky wants to merge 1 commit into
Open
KAFKA-20939: Disable async dns resolution in streams and connect#23364frankvicky wants to merge 1 commit into
frankvicky wants to merge 1 commit into
Conversation
…nd Connect KIP-909's asynchronous bootstrap DNS resolution mode (enabled by a positive bootstrap.resolve.timeout.ms) surfaces failures as BootstrapResolutionException from regular API calls on a permanently broken client that must be discarded and rebuilt by the caller. Neither Kafka Streams nor Kafka Connect is prepared to handle that recovery contract for the clients they create internally, so a user enabling the config would break both frameworks (see KAFKA-20939). Since the config is marked as an evolving/experimental feature (KAFKA-20969), disable it in both frameworks for the time being: - Streams: StreamsConfig forces the config to 0 for the main, restore and global consumers, the producer, and the admin client, logging a warning when a user-supplied value is overridden. - Connect: client config maps built by Worker (connector/task producers, consumers, admin clients, including per-connector overrides) and by the config/offset/status backing stores force the config to 0 via a new ConnectUtils helper; DistributedConfig forces the parsed value to 0 so the herder's own network client also stays in synchronous mode.
frankvicky
changed the title
chia7712
reviewed
Sep 6, 2026
| CommonClientConfigs.warnDisablingExponentialBackoff(this); | ||
| warnIfConnectionsMaxIdleMsLowerThanRebalanceTimeoutMs(); | ||
| return super.postProcessParsedConfig(parsedValues); | ||
| Map<String, Object> configUpdates = new HashMap<>(super.postProcessParsedConfig(parsedValues)); |
Member
There was a problem hiding this comment.
I'm wondering whether we should block it for Connect at all. For instance, group.protocol is not blocked like bootstrap.resolve.timeout.ms here, even though the former could have a bigger impact on Connect.
Contributor
Author
There was a problem hiding this comment.
IIUC, the group.protocol is stable now, and given it's not a major release, I would say we should keep the guard.
m1a2st
reviewed
Sep 6, 2026
m1a2st
left a comment
m1a2st
left a comment
Contributor
There was a problem hiding this comment.
Could you also update the Kafka website documentation?
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.
KIP-909's asynchronous bootstrap DNS resolution mode (enabled by a
positive
bootstrap.resolve.timeout.ms) surfaces failures asBootstrapResolutionExceptionfrom regular API calls on a permanentlybroken client that must be discarded and rebuilt by the caller. Neither
Kafka Streams nor Kafka Connect is prepared to handle that recovery
contract for the clients they create internally, so a user enabling the
config would break both frameworks (see KAFKA-20939).
Since the config is marked as an evolving/experimental feature
(KAFKA-20969), disable it in both frameworks for the time being:
and global consumers, the producer, and the admin client, logging a
warning when a user-supplied value is overridden.
consumers, admin clients, including per-connector overrides) and by the
config/offset/status backing stores force the config to 0 via a new
ConnectUtils helper; DistributedConfig forces the parsed value to 0 so
the herder's own network client also stays in synchronous mode.
Reviewers: Chia-Ping Tsai chia7712@gmail.com, Ken Huang
s7133700@gmail.com