[
https://issues.apache.org/jira/browse/KAFKA-7577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16692143#comment-16692143
]
Daren Thomas commented on KAFKA-7577:
-------------------------------------
This is the detailed behavior of KGroupedTable:
* When a tombstone record – i.e. a record with a {{null}} value – is received
for a key (e.g., DELETE), then only the subtractor is called. Note that,
whenever the subtractor returns a {{null}} value itself, then the corresponding
key is removed from the resulting {{KTable}}. If that happens, any next input
record for that key will trigger the initializer again.
That is the behavior I hoped to see. It seems that my aggregation is following
the semantics of KGroupedStream instead.
> Semantics of Table-Table Join with Null Message Are Incorrect
> -------------------------------------------------------------
>
> Key: KAFKA-7577
> URL: https://issues.apache.org/jira/browse/KAFKA-7577
> Project: Kafka
> Issue Type: Bug
> Components: streams
> Affects Versions: 1.1.0
> Reporter: Daren Thomas
> Priority: Major
>
> Observed behavior of Table-Table join with a Null Message does not match the
> semantics described in the documentation
> ([https://docs.confluent.io/current/streams/developer-guide/dsl-api.html#ktable-ktable-join).]
> The expectation is:
> * Message A results in [A, null] from the Left Join
> * Message null (tombstone) results in null (tombstone) from the Left Join
> The observed behavior was that the null (tombstone) message did not pass
> through the Left Join to the output topic like expected. This behavior was
> observed with and without caching enabled, against a test harness, and
> against a local Confluent 5.0.0 platform. It was also observed that the
> KTableKTableLeftJoinProcessor.process() function was not called for the null
> (tombstone) message.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
