New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sleuth Corrupts Spring Integration Error Message Channel Headers #761
Comments
This code is unwrapping the Message<?> retrievedMessage = getMessage(message);
MessageBuilder<?> messageBuilder = MessageBuilder.fromMessage(retrievedMessage); I can see why you might need the sleuth headers from that, but you should not be propagating any other headers to the "new" |
I added a work around to the stack overflow question (remove the expired headers from the |
Here is a test case that illustrates the problem... @Test
public void errorMessageHeadersRetained() {
QueueChannel deadReplyChannel = new QueueChannel();
QueueChannel errorsReplyChannel = new QueueChannel();
Map<String, Object> errorChannelHeaders = new HashMap<>();
errorChannelHeaders.put(MessageHeaders.REPLY_CHANNEL, errorsReplyChannel);
errorChannelHeaders.put(MessageHeaders.ERROR_CHANNEL, errorsReplyChannel);
this.tracedChannel.send(new ErrorMessage(
new MessagingException(MessageBuilder.withPayload("hi")
.setHeader(TraceMessageHeaders.TRACE_ID_NAME, Span.idToHex(10L))
.setHeader(TraceMessageHeaders.SPAN_ID_NAME, Span.idToHex(20L))
.setReplyChannel(deadReplyChannel)
.setErrorChannel(deadReplyChannel)
.build() ),
errorChannelHeaders));
then(this.message).isNotNull();
String spanId = this.message.getHeaders().get(TraceMessageHeaders.SPAN_ID_NAME, String.class);
then(spanId).isNotNull();
long traceId = Span
.hexToId(this.message.getHeaders().get(TraceMessageHeaders.TRACE_ID_NAME, String.class));
then(traceId).isEqualTo(10L);
then(spanId).isNotEqualTo(20L);
then(this.accumulator.getSpans()).hasSize(1);
then(this.message.getHeaders().getReplyChannel()).isSameAs(errorsReplyChannel);
then(this.message.getHeaders().getErrorChannel()).isSameAs(errorsReplyChannel);
} I believe (if the Message is an
...but I don't know enough about sleuth as to whether that's the whole picture. |
Thanks, @garyrussell for this analysis. It's super helpful. I'll try to fix this next week. |
See https://stackoverflow.com/questions/46971098/spring-integration-error-channel-handling-broken-when-used-with-spring-cloud-sle
Error channel handling from a messaging gateway.
MessagingTemplate
sets up reply/error channel headers and invokes the flow.ErrorMessage
withfailedMessage
payload; new reply/error channels are set up for the error flow.The sleuth interceptor breaks this logic because it restores the "spent" reply/error channel and, when the error flow returns a reply, we get...
It's not clear why sleuth is messing with framework headers; shouldn't it just add the span stuff?
Before interceptor on the error channel...
After interceptor on the error channel...
i.e. the error message channel headers are replaced with channels from the failed message; these channels are no longer valid and the result is the gateway receives no reply (or hangs forever if no timeout is specified).
The text was updated successfully, but these errors were encountered: