Trace and Span IDs are no longer propagated RequestBodyAdvice beans

[philwebb]

Originally raised in spring-projects/spring-boot#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.

[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.

[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

[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.

[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.