You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[Reader] fix: deliver null-value tombstones instead of discarding them (#1482)
* fix(reader): deliver null-value tombstones instead of discarding them
A message published with MessageMetadata.null_value = true (the Pulsar
compaction tombstone convention) was conflated with a deserialization
failure in partitionConsumer.MessageReceived and silently discarded.
Because lastDequeuedMsg was never advanced past the tombstone,
hasMoreMessages kept returning true and Reader.Next blocked forever
when a tombstone was the last message on a topic.
Consumer: when the reader yields an empty payload and msgMeta or the
single-message metadata has null_value set, build a normal message with
payLoad == nil and take the usual dispatch path so lastDequeuedMsg
advances. Real corruption still routes through discardCorruptedMessage.
Producer: set MessageMetadata.null_value / SingleMessageMetadata.null_value
when both Value and Payload are nil, matching the Java client so
Go-produced tombstones carry the flag consumers need.
Message gains an IsNullValue() bool accessor so applications can tell
tombstones apart from empty payloads.
* fix: explicitly reseting err
Quoting Copilot's feedback:
When accepting a tombstone with err == internal.ErrEOM, the code keeps err
non-nil and continues. It works today because err is not used later, but it’s
easy to misread and could become a latent bug if future logic inspects/returns
err after this block. Consider explicitly setting err = nil in the
tombstone/ErrEOM acceptance path to make the intent unambiguous.
* fix: supress lint error
0 commit comments