C0urante commented on PR #12041: URL: https://github.com/apache/kafka/pull/12041#issuecomment-1100581835
If Kafka doesn't retrieve a config because it has no effect due to other configs, isn't it still valid to warn the user? I agree that if there's special internal logic that causes Kafka not to call `get` for a config even though it's applicable for the given client/scenario, then we shouldn't log a warning. The case of (de)serializer properties in the consumer and producer fall into this category. But if we're not calling `get` because of publicly-documented behavior, a warning could be useful in that case to clear up potential misunderstandings by the user of what the configs they passed in actually do. The case of configs related to offset commits like the `auto.commit.interval.ms` fall into this category when no `group.id` is specified. Not sure which category that the internal `internal.throw.on.fetch.stable.offset.unsupported` property falls into to be honest, but since it appears to be intended for use exclusively by Kafka Streams and isn't publicly documented, we probably should keep hiding warning messages that mention it since it probably originates from Kafka Streams anyways and directly not from users. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
