Github user uddhavarote commented on the issue:
    @srdo Thanks for the details. Yeah, I am aware of the drawbacks. But I 
think emitting this next tuple into a different stream, not `default` stream,  
should not replay the tuples in case of failure. That way, we create disjoint 
streams after the Kafka bolt.
    The proposed topology looks good, however, say access to `Topic A` is not 
available due to the authorization or only `RecordMetadata` is required, there 
is no point in reading the whole topic.  I think one would be better off 
emitting the next tuple in the same topology rather than writing a new topology 
to read the data from `RecordMetadata`.
    I would like to suggest that the access to the `Tuple` be provided. along 
with a note about the consequences in such a case. 


Reply via email to