Originally raised in https://github.com/spring-projects/spring-boot/issues/41220 (with a reproducer project).

It looks to me like the reason for lack of Trance and Span IDs is the fix for #32730.

If you run the sample with Spring Boot 3.3.0 with a breakpoint in OncePerRequestFilter.doFilter() you'll see that the call toskipDispatch() return false. With Spring Boot 3.3.1 skipDispatch() returns true because the shouldNotFilterAsyncDispatch() method has been removed.

Comment From: bclozel

@syedyusufh just for confirmation, your sample application is named "webflux" but is actually using Spring MVC. Did you mean to use WebFlux instead? In this case, can you try with spring.main.web-application-type=reactive?

Also, could you elaborate on why you're relying on a trace being present during an asynchronous write? This is outside the scope of the controller handler, quite similar to spawning a new thread to process the request with Spring MVC async support (in this case, the threadlocals would not be set there automatically).

I understand that #32730 changes the behavior here, but I'm not sure this was ever intended/supported.

Comment From: syedyusufh

Hi @bclozel Our applications have always been Spring Web + Spring WebFlux combined, wherein Tomcat supports the Mono via Async.

This has been working fine for us since Spring Boot 2.5.x atleast and until the new v3.3.1

Comment From: bclozel

@syedyusufh ok thanks for confirming - so the "webflux" in your sample is a typo, as it was never the intent to use WebFlux. I'll see if there's a way to support async dispatches again without undoing the previous fix.

Comment From: bclozel

I have a commit ready for this but I'm not in favor of applying it right now for the following reasons:

  • the main goal of this filter is to observe the handling of the HTTP request, especially in controllers
  • we never guaranteed that observation scopes would be reinstated during async dispatches
  • handling ASYNC dispatch types would also mean that the onScopeOpened method would be called multiple times (once for REQUEST dispatch, and another time for ASYNC). This is meant to be used to handle HTTP response headers. At the point of ASYNC dispatches, response headers are likely to be read-only.

I do understand that the trace id is not logged anymore for ResponseBodyAdvice implementations, but right now I'm leaning towards this being a niche use case, compared to the performance and consistency aspects.

I'm closing this issue for now, but we can always reconsider if we receive more feedback and descriptions of use cases that are not possible anymore.

Comment From: syedyusufh

@bclozel TracingContext is lost in RestControllerAdvice as well where you define ExceptionHandler for logging and throwing user defined exceptions.

Also, ResponseBodyAdvice helps customize the responseBody and definitely any info / failure there needs to be logged along with the original TraceContext

Our implementation is quite similar to what is mentioned in this official documentation page https://docs.spring.io/spring-boot/reference/web/reactive.html#web.reactive.webflux

Having this been available since atleast Spring Boot v2.5.x, kindly reconsider. Thanks

Comment From: bclozel

Reopening to check the @ExceptionHandler case.