Automatic context propagation stops working after an error occurs

[surmabck]

Expected Behavior

I believe WebFilters should have auto context propagation regardless if error occurred or not.

Actual Behavior

Automatic context propagation enabled via Hooks.enableAutomaticContextPropagation(); stops working when error was being handled in WebFilter. Once error is caught, all further WebFilters are going to be stripped of MDC context.

Reproductor

I've prepared reproducer with tests describing positive and negative(failing) flow, here -> https://github.com/surmabck/spring-boot-3xx-micrometer-issues/tree/only-reactor

FYI, ticket was originally opened against reactor-core

[chemicL]

ExceptionHandlingWebHandler assembles the WebFilters and then actual handlers, and on top of that wraps around the existing WebExceptionHandlers using Mono.onErrorResume.

The fact that the Observation is created in a WebFilter (ServerHttpObservationFilter) makes it impossible for the WebExceptionHandlers to see the Observation, as the Context is limited to the upstream of the chain.

In order to allow WebExceptionHandlers to see an Observation, Spring would need to initiate it earlier than in a WebFilter.

As a side note, this doesn't have anything to do with automatic context propagation from Reactor 3.5.3. If handle or tap operators were used to log, they would not see the MDC context populated either, as the Reactor Context is empty.

[bclozel]

As discussed with @chemicL, this is a limitation of the current design which is using a WebFilter. The exception handling mechanism is applied with ExceptionHandlingWebHandler, which is a HttpHandlerDecorator. WebFilter instances are applied at a higher level and are not aware of this.

This limitation is serious enough that I'm considering this a bug and should be fixed in 6.0.x. A possible solution would be to reimplement the instrumentation as a HttpHandlerDecorator itself, but this needs to validated. I'm scheduling this issue for 6.0.x but this can be revisited depending on our findings with HttpHandlerDecorator. As a result, the existing WebFilter should be deprecated.