Spring In spring webflux, if Hooks.enableAutomaticContextPropagation() is enabled, the same traceId will be used around.

Issue Summary

In spring webflux, if Hooks.enableAutomaticContextPropagation() is enabled, the same traceId will be used around.

Since it is reproduced by a very simple code, it is possible that it is simply a misconfiguration. Or there may be a similar issue.

Reproduction Procedure

I have prepared code to reproduce it.

git clone git@github.com:be-hase/webflux-tracing-issue.git
./gradlew bootRun

curl http://localhost:8080/hello
curl http://localhost:8080/hello
curl http://localhost:8080/hello
curl http://localhost:8080/hello
...

Looking at the application log, the traceId is always the same.

This example uses micrometer-tracing-bridge-brave, but the same problem occurs with micrometer-tracing-bridge-otel

Why

Normally TraceContext should be reverted to null after processing the request. https://github.com/openzipkin/brave/blob/9f4f166f97a3645e7514c0db920eb02bb3666e7d/brave/src/main/java/brave/propagation/ThreadLocalCurrentTraceContext.java#L109

hen Hooks.enableAutomaticContextPropagation is enabled, the value returned to null by the ObservationThreadLocalAccessor appears to be overwritten again. https://github.com/openzipkin/brave/blob/9f4f166f97a3645e7514c0db920eb02bb3666e7d/brave/src/main/java/brave/propagation/ThreadLocalCurrentTraceContext.java#L123

If Hooks.enableAutomaticContextPropagation is not used, it works well, but Hooks.enableAutomaticContextPropagation is useful for MDC and other context propagation, so I want to use Hooks.enableAutomaticContextPropagation.

Comment From: bclozel

I think this is a duplicate of https://github.com/micrometer-metrics/tracing/issues/363. Upgrading your sample application to Spring Boot 3.1.5-SNAPSHOT solves the issue for me.