Spring Webclient Header Propagation

[cantaylancapraz]

Hi,

Until this time, I was using spring cloud sleuth for propagation. I was using b3 propagation. However, after upgrading to spring 3.0 I removed sleuth, switched to micrometer tracing. I started not being able to propagate b3 headers.

I am using Spring 3.0 + Webflux + Webclient.

To be more specific, my request is:
When I call an endpoint that calls the external source via WebClient, headers such as X-B3-SpanId should be added if there is not, and propagate if there exists.

I did a lot of research, tried many ways, but couldn't solve my problem. I couldn't find any documentation or sample project that provides how to do it. Nothing I've tried has worked either.

I need the guidance of community.

Best regards

[marcingrzejszczak]

Please check this sample for reference https://github.com/micrometer-metrics/micrometer-samples/tree/main/webflux

[cantaylancapraz]

Thanks

I've actually seen this. But I believe it is very inefficient to apply this to many points in the code.
Maybe we can think about how we can make this work more practical.

[jonatan-ivanov]

I think I might miss something but your issue is that B3 headers are not propagated when you receive a request with webflux and in the controller you want to send another with webclient?
Do you see the W3C header being propagated (traceparent)?

[cantaylancapraz]

Yes.

When I don't set management.tracing.propagation.type as B3, traceparent header is propagated.

[cantaylancapraz]

By the way, now I now able to pass a single b3 header. I will create a sample project and share it here.

However, following headers are still not propagated.
x-b3-parentspanid, x-b3-sampled, x-b3-spanid, x-b3-traceid

[jneate]

@cantaylancapraz is a B3 header being propagated?

The issue we have is that after the upgrade it's defaulting to a single B3 header instead of the multiple X-B3 headers.
If we supply our own Propagation.Factory via

@Bean
Propagation.Factory get() {
    return B3Propagation.newFactoryBuilder().injectFormat(B3Propagation.Format.MULTI).build();
}

we gain the X-B3 multi headers but lose the propagation of remote baggage headers so that might fix your issue but it raises another one for us.

Not sure if there is a better/working way of forcing the propagation to use Multi headers instead of single?

(Related remote baggage fix micrometer-metrics/micrometer#3564)

[marcingrzejszczak]

You're close @jneate , just create your beans like this

@Bean
		BaggagePropagation.FactoryBuilder myPropagationFactoryBuilder(
				ObjectProvider<BaggagePropagationCustomizer> baggagePropagationCustomizers) {
			Factory delegate = B3Propagation.newFactoryBuilder().injectFormat(B3Propagation.Format.MULTI).build();
			FactoryBuilder builder = BaggagePropagation.newFactoryBuilder(delegate);
			baggagePropagationCustomizers.orderedStream().forEach((customizer) -> customizer.customize(builder));
			return builder;
		}

[artemptushkin]

@marcingrzejszczak Hi, I bumped into this issue

it's defaulting to a single B3 header instead of the multiple X-B3 headers

I wonder why is it single b3 now and not multi? Is it documented somewhere? (I can not find) It's actually a breaking change that we could bypass, IMO

Can we expose it as a property to make it customizable on the consumer side?

Related to this code

[shakuzen]

@artemptushkin see spring-projects/spring-boot#35096. We're working on improving the situation to improve flexibility and backward compatibility.

[artemptushkin]

@shakuzen this is different that you post, I'm asking about multi header approach

We had 3 headers with sb 2.7, e.g. x-b3-traceid and others
but now by default, it's just one header: b3

Please see this code https://github.com/spring-projects/spring-boot/blob/157b71b333473c2633b17362df1be83d6f9eaaed/spring-boot-project/spring-boot-actuator-autoconfigure/src/main/java/org/springframework/boot/actuate/autoconfigure/tracing/BraveAutoConfiguration.java#L183

[shakuzen]

My apologies that things weren't reflected on the issue I linked or the pull request linked from there at the time I made my comment (I also didn't explicitly mention the linked pull request). We had already discussed internally about the requests here and elsewhere for b3 multi header support, and it was subsequently added to the pull request. Please see spring-projects/spring-boot#35611. That will add support for configuring b3 multi via properties.