fix(webflux): register reactor hook in createWebFilter and add filter.

[amit306]

Fixes #17858

createWebFilter() and addFilter() now always register the Reactor
context propagation hook. The AndRegisterReactorHook variants are
deprecated and delegate to these methods.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: amit306 / name: amit306 (2f62a78)

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

This PR makes Spring WebFlux 5.3 client/server telemetry automatically register Reactor’s context-propagation hook and adds tests to verify OTel context survives a thread switch.

Changes:

• Register ContextPropagationOperator inside SpringWebfluxClientTelemetry.addFilter() and SpringWebfluxServerTelemetry.createWebFilter().
• Make the explicit “...AndRegisterReactorHook” APIs delegate to the now-hook-registering methods.
• Add unit tests asserting span context propagation across Schedulers.boundedElastic() thread switching.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 6 comments.

File	Description
instrumentation/spring/spring-webflux/spring-webflux-5.3/library/src/test/java/io/opentelemetry/instrumentation/spring/webflux/v5_3/ReactorHookRegistrationTest.java	Adds tests validating context propagation after hook auto-registration.
instrumentation/spring/spring-webflux/spring-webflux-5.3/library/src/main/java/io/opentelemetry/instrumentation/spring/webflux/v5_3/SpringWebfluxServerTelemetry.java	Auto-registers Reactor hook when creating the server WebFilter.
instrumentation/spring/spring-webflux/spring-webflux-5.3/library/src/main/java/io/opentelemetry/instrumentation/spring/webflux/v5_3/SpringWebfluxClientTelemetry.java	Auto-registers Reactor hook when adding the client ExchangeFilterFunction.

Comments suppressed due to low confidence (1)

instrumentation/spring/spring-webflux/spring-webflux-5.3/library/src/main/java/io/opentelemetry/instrumentation/spring/webflux/v5_3/SpringWebfluxClientTelemetry.java:50

• This now registers a global Reactor hook even when addFilter() returns early because the filter is already present. If the intent is to register the hook only when enabling instrumentation via this API, consider moving hook registration after the ‘already instrumented’ check, and/or guarding registration so it only happens once. This avoids repeated global work and reduces surprising side effects when callers invoke addFilter() defensively.

  public void addFilter(List<ExchangeFilterFunction> exchangeFilterFunctions) {
    ContextPropagationOperator.builder().build().registerOnEachOperator();
    for (ExchangeFilterFunction filterFunction : exchangeFilterFunctions) {
      if (filterFunction instanceof WebClientTracingFilter) {
        return;
      }

[singhvibhanshu]

LGTM, just a nit:

opentelemetry-java-instrumentation/instrumentation/spring/spring-webflux/spring-webflux-5.3/library/README.md

Line 81 in 4c57afb

return webfluxServerTelemetry.createWebFilterAndRegisterReactorHook();

Suggested change: return webfluxServerTelemetry.createWebFilter();

[amit306]

LGTM, just a nit:

opentelemetry-java-instrumentation/instrumentation/spring/spring-webflux/spring-webflux-5.3/library/README.md

Line 81 in 4c57afb

return webfluxServerTelemetry.createWebFilterAndRegisterReactorHook();

Suggested change: return webfluxServerTelemetry.createWebFilter();

@singhvibhanshu , Done, Thanks for catching this

[singhvibhanshu]

May I ask for a review from @open-telemetry/java-instrumentation-approvers when any of them get a chance?

Thanks!

[amit306]

Ready for review, addressed all feedback. Could someone from @open-telemetry/java-instrumentation-approvers please take a look?

[laurit]

#17858 asks whether the reactor hook should be always registered. Did you attempt to fina an answer to that question? What are the benefits of registering the reactor hook? What would we loose if we did it the other way around and never registered it in these methods?

[amit306]

#17858 asks whether the reactor hook should be always registered. Did you attempt to fina an answer to that question? What are the benefits of registering the reactor hook? What would we loose if we did it the other way around and never registered it in these methods?

@laurit When using Spring WebFlux library instrumentation, the reactor context propagation hook is generally required for OTel context to remain available across the reactive pipeline ( thread switches and scheduler). Without this, spans may be created without the parent context, which will create a broken parent-child relationships, which is hard to identify.

Registering the hook directly in createWebFilter() and addFilter() means users get correct behavior by default.
registerOnEachOperator method is thread-safe so calling multiple times has no impact.

If these methods do not register the hook, the user must remember to call ContextPropagationOperator. Missing this call, it can lead to broken trace parent-child relationship and hard to debug.