You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "sanghyeok An (Jira)" <ji...@apache.org> on 2025/11/27 11:39:00 UTC
[jira] [Comment Edited] (KAFKA-19923) Kafka Streams throws ClassCastException with different Consumed instances.
[ https://issues.apache.org/jira/browse/KAFKA-19923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18041039#comment-18041039 ]
sanghyeok An edited comment on KAFKA-19923 at 11/27/25 11:38 AM:
-----------------------------------------------------------------
Could you let me know where would be a good place to document this guideline? I’d be happy to take a first pass at it.
Regarding your comment;
And yes, we could maybe add some code when merging nodes, to verify that we don't get conflicting configs passed in, and throw a better exception with a clear error message.
As we discussed earlier, there is currently no straightforward way to detect semantic conflicts among {{TimestampExtractor}} or Serdes implementations.
If Kafka Streams has any plan to support semantic equivalence checks for {{TimestampExtractor}} or Serdes in the future, please let me know. I would be glad to contribute.
However, I understand that such a change would likely be breaking. (Maybe 5.0.0???? )
was (Author: JIRAUSER303328):
*Could you let me know where would be a good place to document this guideline? I’d be happy to take a first pass at it.*
Regarding your comment;
And yes, we could maybe add some code when merging nodes, to verify that we don't get conflicting configs passed in, and throw a better exception with a clear error message.
As we discussed earlier, there is currently no straightforward way to detect semantic conflicts among {{TimestampExtractor}} or Serdes implementations.
If Kafka Streams has any plan to support semantic equivalence checks for {{TimestampExtractor}} or Serdes in the future, please let me know. I would be glad to contribute.
However, I understand that such a change would likely be breaking. (Maybe 5.0.0???? )
> Kafka Streams throws ClassCastException with different Consumed instances.
> --------------------------------------------------------------------------
>
> Key: KAFKA-19923
> URL: https://issues.apache.org/jira/browse/KAFKA-19923
> Project: Kafka
> Issue Type: Bug
> Components: streams
> Reporter: sanghyeok An
> Assignee: sanghyeok An
> Priority: Minor
>
> Kafka Streams throws a ClassCastException when using different Consumed instances for the same topic.
> For example:
> {code:java}
> builder.stream("A", Consumed.with(Serdes.String(), Serdes.String()))
> .peek((k, v) -> System.out.println(k));
> builder.stream("A", Consumed.with(Serdes.ByteArray(), Serdes.ByteArray()))
> .peek((k, v) -> System.out.println(k));
> {code}
>
> Since both use the same topic name and the same ConsumedInternal configuration for auto offset reset, these two StreamSourceNodes are merged during topology building.
>
> As a result, the Topology is built successfully.
>
> However, when the StreamThread starts, the consumer begins to receive records from the broker, and the records flow through the pipeline, a ClassCastException is thrown at runtime.
>
> In my opinion, we have two options:
> # Document this behavior.
> # When merging source nodes, the builder should consider the full ConsumedInternal configuration (for example, key/value SerDes and timestamp extractor), instead of only the auto offset reset policy.
>
> I think option 1 is also acceptable, because Kafka Streams will fail fast with a ClassCastException before the consumer commits any offsets.
>
> Option 2 would require more substantial changes in Kafka Streams, because TimestampExtractor and key/value SerDes do not expose a straightforward way to check semantic equivalence.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)