Sleuth context cleanup (?) in direct channels

[gigermocas]

Hello,

I'm trying to wrap my head around something, I'm using spring integration and sleuth in a highly concurrent tcp server.
I have a tcp inbound adapter that sends its message to a handling flow through a direct channel.
I found that the great majority of the requests have the same brave trace id, which was something I was not expecting and is making tracing unusable.
My initial feeling is that the global TracingChannelInterceptor is not cleaning up correctly after itself before finishing with the thread, but I'm doubting it as this seems like such an integral component.

I think I've reproduced the behavior in this example:

@SpringBootApplication
@EnableIntegration
public class TraceTestApplication {

	public static void main(String[] args) {
		SpringApplication.run(TraceTestApplication.class, args);
	}

	@Bean
	MessageChannel requestChannel() {
		return MessageChannels.direct()
				.get();
	}

	@Bean
	IntegrationFlow main(Tracer tracer) {
		return IntegrationFlows.from(requestChannel())
				.handle(m -> {})
				.get();
	}

	@Autowired
	Tracer tracer;

	@EventListener
	public void onApplicationEvent(ContextRefreshedEvent event) {
		MessagingTemplate messagingTemplate = new MessagingTemplate(requestChannel());

		IntStream.range(0, 50).parallel()
				.forEach(i -> {
					if (tracer.currentSpan() != null) {
						System.out.println("what!!");
					}
					messagingTemplate.send(MessageBuilder.withPayload(i).build());
				});
	}

I was not expecting for a new execution to have an already created span, is this expected behavior?

[artembilan]

I think this is exactly what I've caught yesterday: #3649 (comment).

Let's consider to move this as an issue to https://github.com/spring-cloud/spring-cloud-sleuth/issues!
We don't manage that TracingChannelInterceptor over here.

[gigermocas]

Got it, thanks.