Open deepesh-verma opened 3 years ago
Hello @deepesh-verma, nice to see you again! That's a very interesting issue, thanks. TBH I don't know much about b3 headers, but here's what I thought about this.
Since sleuth uses thread-based MDC for the headers, I think it's expected that they won't be propagated to a new message that'll be consumed by a different thread, so I guess this is more an enhancement than a bug, right?
The solution I've used in the past for this kind of problem is to wrap the original message into a message containing the ThreadLocal values, and then set the ThreadLocal values again in message consumption while unwrapping the message so the user receives the original message.
But this has implications that go beyond the application's boundaries, because it interferes with the messages' contracts, which might be consumed by a different application, so I don't think it's necessarily a good solution for a framework.
What do you think, did you think of a solution for this?
As always it'd be nice to hear @garyrussell's and @artembilan's inputs.
Thanks again!
It's probably caused by this.
I am not sure what the root cause is; I haven't looked closely at how sleuth instruments the message and when it adds/removes the headers.
The b3 header generated by
spring-cloud-sleuth
for Kafka messages is not getting propagated to retry topics. The same message when sent to retry topic after an exception, has a new b3 header.Please see the
whenMessageSendWithB3HeaderToRetryableTopic_sameHeaderShouldBeCarriedForward
test case below-Complete test class - https://github.com/deepesh-verma/spring-kafka-sample/blob/main/src/test/java/dev/deepesh/springkafkasample/RetryableTopicIntegrationTest.java Repository with complete code - https://github.com/deepesh-verma/spring-kafka-sample