Trace context not available with WebFlux

[jumal]

Bug report

The trace context is not always available with WebFlux.

• Spring Boot version: 2.1.0
• Spring Cloud version: Greenwich M3. Same issue with Greenwich M2. No issue with Greenwich M1
• Sample project: https://github.com/jumal/sleuth-webflux-no-trace-context-issue

Trying to access propagated extra fields fails due to the unavailability of the trace context in Webflux.

The following code, that used to work with Spring Cloud Finchley and Greenwich M1, does not work anymore with Spring Cloud Greenwich M2 and M3:

• application.properties

spring.sleuth.propagation-keys=X-Field2

• Test

    webClient
                .post().uri("/test")
                .contentType(APPLICATION_JSON)
                .accept(APPLICATION_JSON)
                .header("X-Field2", "field2")
                .body(just(entity), TestEntity.class)
                .exchange();

• Handler

    Mono<ServerResponse> save(ServerRequest request) {
        return request.bodyToMono(TestEntity.class)
                .map(TestEntity::setContext)
                .flatMap(repository::save)
                .flatMap(entity -> ok().build());
    }

• TestEntity

    TestEntity setContext() {
        field2 = ExtraFieldPropagation.get("X-Field2");
        return this;
    }

ExtraFieldPropagation.get("X-Field2") returns null because the trace context is not available.

[jumal]

Added sample project to reproduce the issue: https://github.com/jumal/sleuth-webflux-no-trace-context-issue

[riba2101]

Hi there,

I've found a similar issue when used in a ReactiveAuthenticationManager with ExtraFieldPropagation.set on a client the context is null and on the server side, ExtraFieldPropagation.get returns null.

ReactiveAuthenticationManager.authenticate calls server and tries to set some fields that should be logged/used on the server side

[anatoliy-balakirev]

Not exactly the same, but seems to be similar:
#1199

[marcingrzejszczak]

Absolutely. I had a chat with @bsideup and he mentioned that there's a bug in Reactor.

[bsideup]

@marcingrzejszczak just to clarify:
This is not a bug in Reactor, rather in Sleuth's Reactor integration, but we're working on native trac(k)ing support in Reactor Core (to be used by Sleuth) where the bug should be fixed:
reactor/reactor-core#1481

[marcingrzejszczak]

Ah thanks for the clarification @bsideup. I must have misunderstood you.