BootUI on Spring WebFlux — support status

ReactiveBootUiHandlerAdapter delegates BootUI controller dispatch to WebFlux's fully configured request-mapping adapter on Reactor's bounded-elastic scheduler. This keeps argument resolution, blocking network calls, advisor/classpath scans, heap and JVM diagnostics, downloads, and filesystem handlers off Reactor Netty event-loop threads without duplicating scheduler code across the controllers shared with Spring MVC. Selection follows the existing class-level ${bootui.api-path:...} mapping convention rather than an endpoint allowlist, so custom API mounts and newly shared controllers inherit it automatically. The shell, static assets, host-application controllers, the host's own WebFlux blocking-execution policy, and requests rejected by the preceding safety filters remain untouched.

The MySQL operational panel follows this shared-controller pattern: the engine owns collection and the sanitized cache, while both Spring autoconfigurations bind the same GET/POST contract. GET <api-path>/mysql, manifest discovery, and get_mysql_report must never acquire a connection or execute SQL. Only explicit POST <api-path>/mysql/read / mysql_read collects, off the Netty event loop through ReactiveBootUiHandlerAdapter, with the same single-flight and panel read-only policy as MVC.

Default/named JDBC datasource discovery is reused; installing a MySQL driver without a supported datasource does not provide diagnostics. The same seven startup bootui.mysql.* caps apply and require restart. Live tests cover least-privilege collection, driver cleanup, and positive MySQL REST/MCP/CLI behavior on default and custom mounts. A reactive app with only R2DBC remains unavailable with a JDBC-specific hint.

KafkaController, RabbitController, and JmsController, plus their template/listener-factory BeanPostProcessor capture pairs, carry no ConditionalOnWebApplication or reactive-specific code. The panels and their Live Activity MESSAGING capture therefore work identically to the servlet adapter with zero adapter changes. JMS remains an imperative, blocking broker API, but its work runs on the application's JMS template/listener threads; the WebFlux panel only reads the shared in-memory recorder.

FaultToleranceController is framework-neutral: Resilience4j registries and Spring Retry @Retryable metadata are plain beans with no servlet or reactive coupling. Resilience4j's event publishers plus the additive BootUiRetryListener bean feed the shared FaultToleranceEventRecorder from whatever thread the protected call runs on, so the panel and its Live Activity FAULT_TOLERANCE entries work with zero adapter-specific code. Resilience4j's reactive operators (ReactorCircuitBreaker and friends) publish through the same registries and event publishers as the imperative ones, so reactive pipelines use the same read path. The reactive sample application declares Resilience4j — and deliberately not Spring Retry, so the two Spring samples between them cover both halves of the backend's optional-dependency guards — and exercises its policies from a boundedElastic scheduler thread, which WebFluxFaultToleranceIntegrationTest asserts reaches the panel report.

The Cache panel's tier and native-statistics reporting is identical on both Spring adapters: it is produced by the shared SpringCacheProvider and its classloading-gated inspectors, which depend only on Spring's cache abstraction and the cache provider's own public API, never on a servlet or reactive type. A WebFlux application configured with spring.cache.type=simple shows the same single local in-memory map tier — and the same honest "a plain map records nothing" statistics state — the servlet adapter shows for that configuration.

CRaC uses the same framework-neutral scanner and Spring runtime inventory on MVC and WebFlux. Its pool inventory includes R2DBC factories, and its task/scheduling checks use Spring context APIs rather than servlet types. Generated assets still target a JVM process and Spring's checkpoint lifecycle; they do not imply Quarkus or native-image support.

@ControllerAdvice, @ExceptionHandler, and @ResponseStatus all live in spring-web, so one SpringErrorContractProvider serves both stacks by reading bean metadata. The only reactive-specific behavior is in the provider's return-type analysis, which unwraps Mono, Flux, CompletionStage, CompletableFuture, Callable, DeferredResult, and WebAsyncTask — matched by class name, so nothing links Reactor — before classifying the declared response body. A reactive handler returning Mono<ResponseEntity<ErrorBody>> reports the same body category and the same runtime-built status as its servlet equivalent, and WebFlux's functional ServerResponse is treated like ResponseEntity: a runtime-built status with a runtime-decided body. Neither stack instantiates or invokes a handler — discovery reads bean types without creating them, so a FactoryBean declaring advice is never forced into existence just to build the catalogue.

The Spring adapter tells the REST API scanner whether the running context is servlet or reactive. Only RAPI-RESP-010 uses it: Spring MVC discards the returned body when @ResponseStatus sets a reason, while WebFlux applies the status, ignores the reason, and still writes the body. The rule therefore reports on Spring MVC and is SKIPPED on WebFlux.

SQL Trace. Statement rankings and request-route attribution (GET /bootui/api/sql-trace/insights) are served from the framework-neutral SqlTraceInsightsService; request evidence comes from the reactive HttpExchangeTraceRegistry, which also captures the best-matching reactive route pattern so routes group by template rather than by masked path. Fidelity gap, accepted: a reactive request is not pinned to one thread, so serving-thread correlation is deliberately not offered — the report advertises TRACE_ID and TIME_WINDOW only, and work it cannot place lands in the explicit unattributed/ambiguous buckets rather than being guessed onto a route. The HttpExchangeTraceRegistry ships with the OpenTelemetry correlation configuration, so on a WebFlux application without an OpenTelemetry starter, route attribution reports itself unavailable — naming that requirement — instead of advertising correlation tiers over an empty candidate list. Statement rankings are unaffected.

Transactions. Capture is identical to the servlet adapter: BootUI contributes a TransactionExecutionListener through Spring Boot's standard transaction-manager customization and completes registration for user-defined ConfigurableTransactionManager beans after singleton initialization, observing any configurable blocking transaction manager a WebFlux application still uses (e.g. JDBC repositories behind a thread-blocking data access layer). Fidelity gap, accepted: a WebFlux application backed only by a ReactiveTransactionManager (R2DBC) has no ConfigurableTransactionManager bean to observe — Spring's transaction-execution listener hook exists solely on the blocking SPI — so the panel reports "No configurable PlatformTransactionManager bean is available" rather than silently showing an empty table.

Exceptions. Known fidelity gap, accepted, documented in code (ReactiveBootUiExceptionHandler's Javadoc): a @RestController's own local @ExceptionHandler method consumes an exception inside the WebFlux dispatch pipeline, before any WebExceptionHandler sees it. This is narrower capture than the servlet adapter's resolver-chain approach, where BootUiExceptionHandlerResolver runs at HIGHEST_PRECEDENCE in the same chain @ExceptionHandler resolution uses. An application-level @ExceptionHandler will suppress BootUI's capture on WebFlux where it would not on servlet. Unhandled exceptions (the common case) are captured identically on both stacks.

REST Client. Availability is gated on RestClientTraceRecorder#hasInstrumentedClient() (a WebClient.Builder auto-configured with the BootUI customizer must have been built). The RestClient/RestTemplate interceptors are not linked on a WebFlux-only classpath (their @ConditionalOnClass gate requires spring-boot-restclient), so the recorder only sees WebClient customization on this stack — the correct signal.

WebSockets. Endpoint topology is read from the reactive SimpleUrlHandlerMapping beans that map org.springframework.web.reactive.socket.WebSocketHandlers. Fidelity gap, accepted and reported honestly:@EnableWebSocketMessageBroker and its WebSocketHandlerDecoratorFactory/ChannelInterceptor seams are servlet-only, so the reactive report sets frameCaptureSupported=false with that reason and the panel shows endpoints only — it never fabricates a frame log or an empty capture buffer. There is likewise no reactive session registry, so sessionTrackingSupported=false and the Sessions table reads not supported on this stack rather than implying no client is connected.

The original four — HTTP Exchanges, SQL Trace, Exceptions, and Security Logs — are already captured reactively by the panels in §6.2/§6.3. The five newer entry types added by the Live Activity event-type extension workstream (see Live Activity) reuse the same framework-neutral engine buffers regardless of stack, because their capture wiring (BootUiEngineConfiguration) is gated purely on classpath/bean presence, never on ConditionalOnWebApplication:

• Cache and Scheduled Tasks are read from the same CacheActivityRecorder/ScheduledTaskRunStore the §6.1 panels already expose unmodified.
• Mail is read from the same EmailCaptureService/EmailController the §6.1 Email panel exposes.
• Messaging is read from the independent KafkaActivityRecorder, RabbitActivityRecorder, and JmsActivityRecorder buffers, fed by the same template/listener-factory BeanPostProcessor wrapping the servlet adapter uses.
• REST/WebClient calls are read from the same RestClientTraceRecorder fed by BootUiEngineConfiguration's WebClientCustomizer; capture is active on both stacks, and the standalone panel is now wired reactively too (§6.3).

The servlet adapter's LiveActivityController additionally depends on two things with no reactive equivalent. One is a ServletRequestHandledEvent listener, which exists purely as an SSE-refresh trigger, not a data source. The other is a thread-based LiveActivityCorrelator that stitches a request to its downstream activity via serving-thread identity — meaningless on Reactor Netty, where a request is not served start-to-finish on one dedicated worker thread.

The Live flow service map (GET {api}/activity/service-map) needed no reactive-specific work. LiveServiceMapController injects only beans both stacks register — the shared HttpExchangesController plus the engine's ConnectionPoolService, SqlTraceRecorder, RestClientTraceRecorder, KafkaActivityRecorder, RabbitActivityRecorder, and CacheActivityRecorder. It returns a stable core DTO, so one class registered in both BootUiAutoConfiguration and BootUiReactiveAutoConfiguration makes Spring MVC and WebFlux serve a byte-identical map, including its cache dependency and opaque flow correlation. All interpretation (identity normalization, configured-versus-observed state, conservative SQL attribution, cardinality bounds) lives in the framework-neutral ServiceMapAssembler. The map refreshes off the same ReactiveBootUiChangeStream SSE tick the feed uses; it performs no additional polling and contacts nothing. Cache is reported as an available source only after the shared post-processor successfully instruments at least one CacheManager, so an enabled but disconnected recorder never overstates runtime support.

The map's opaque ServiceMapInteractionDto.flowId — derived one-way from whatever trace id was active when an interaction completed — needed no reactive-specific work either. BootUiReactiveAutoConfiguration already installs the same ReactiveOtelTraceIdProvider on the HTTP exchange, SQL, REST-client, and cache recorders. ServiceMapAssembler only ever reads whatever trace id those recorders already captured, so causal flow correlation on this adapter is byte-identical to Spring MVC and Quarkus wherever OpenTelemetry is configured.

ReactiveActivitySignalFilter takes an ObjectProvider<ReactiveLiveActivityController> rather than a direct reference. WebFilter beans are eagerly resolved by WebFlux at startup to build the filter chain, so a direct constructor dependency would force-eager the controller and defeat its place in BootUiReactiveAutoConfiguration.LAZY_CONTROLLER_CLASS_NAMES. Calling .getIfAvailable() per request is safe because ReactiveBootUiChangeStream.signal() is already a no-op with no subscribers, and the first /stream request naturally resolves (and creates) the controller bean once the panel is opened.

A reactive-only ReactiveOtelTraceIdProvider reads Span.current() unconditionally at every capture point: HTTP exchange (via a new ReactiveHttpExchangeTraceFilter feeding a side-buffer HttpExchangeTraceRegistry, since Actuator's HttpExchange model has no trace-id field), SQL (SqlTraceRecorder.setTraceIdProvider), exceptions (ReactiveBootUiExceptionHandler.setTraceIdProvider), and security events (ReactiveSecurityLogsController.setTraceIdProvider

• ReactiveSecurityEventTraceRegistry). This replaces the earlier inbound-header/SLF4J-MDC-only reliance. All four are wired by BootUiReactiveAutoConfiguration.ReactiveOpenTelemetryCorrelationConfiguration, gated only on the OpenTelemetry SDK being present (matching Quarkus's own Capability.OPENTELEMETRY_TRACER gate). It is deliberately not also gated on bootui.telemetry.enabled, which governs BootUI's own span export for the Traces/AI Framework panels — a separate concern from reading the id of a span the application's own tracing already started.

This alone is not sufficient. WebFlux has no thread-per-request invariant: a single request's reactive chain hops between the Netty event loop, boundedElastic (blocking JDBC), and parallel schedulers. Span.current() only resolves correctly across those hops when Reactor's automatic context propagation is enabled (Hooks.enableAutomaticContextPropagation()). Spring Boot 4.1 only calls that when spring.reactor.context-propagation=auto, and its own default is limited. Without auto, the trace-stamping code is wired correctly but reads an empty/invalid span everywhere except by coincidence on the thread the request started on. BootUiActuatorDefaultsEnvironmentPostProcessor now contributes spring.reactor.context-propagation=auto as an overridable default (the same "library default, host always wins" pattern used for management.tracing.sampling.probability) whenever the application is reactive and the OpenTelemetry SDK is present — see §7 for how this was found.

Known, accepted residual limitations:

• Correlation is still trace-id-primary, exactly like Quarkus. A request with no active tracing span at all (for example, OpenTelemetry entirely absent) still shows every signal flat/uncorrelated rather than nested, since there is no id to key on. This is not WebFlux-specific — the same is true of the Quarkus adapter today.
• HttpExchangeTraceRegistry#match (and its servlet sibling RequestCorrelationRegistry) deliberately requires a unique method+path+time-window candidate. Two genuinely concurrent identical requests (the same endpoint hit twice within roughly the same tens of milliseconds, with no other distinguishing signal) correlate to neither rather than risk attributing one request's trace id to the other. Both still show in the feed; they simply render without a nested SQL/exception child until a less ambiguous signal is added.
• The servlet adapter's thread-based correlation (LiveActivityCorrelator) is not ported — it has no reactive equivalent.

Two unsupported checks were replaced without changing the 25-rule count: the non-existent reactive spring.security.debug switch and the unprovable global-bean audience-validator check gave way to host-configured Actuator show-values=always detection for web-exposed env/configprops endpoints and RFC 7662 plain-HTTP opaque-token introspection detection.

Existing findings were narrowed where needed. Credentialed CORS now targets the legal allowedOriginPatterns="*" case; CSP absence is a LOW contextual review (and report-only policies are called out as non-enforcing); static JWT keys are INFO rotation advice; HTTPS/Actuator findings avoid claiming knowledge of external deployment policy; and the mixed bearer/login rule uses WebFlux's real NoOpServerSecurityContextRepository remediation rather than servlet-only SessionCreationPolicy.

A follow-up parity review brought the catalogue to 26 rules: SEC-RXF-CSRF-001 and SEC-RXF-SESSION-001 now also recognize formLogin() chains, not just OAuth2/OIDC login filters, and the new SEC-RXF-CORS-003 flags broad allowedOriginPatterns (e.g. https://*) to match the servlet stack's SEC-CORS-006.

The cross-stack accuracy audit then retired duplicate missing-authorization rules SEC-RXF-AUTHZ-002/003 and added the INFO structural chain-ordering check SEC-RXF-AUTHZ-004, leaving 25 active rules. It also separates Basic/browser credentials from header-only bearer APIs, OAuth client grants from login, and effective Actuator access from inclusion settings. Unknown observations remain incomplete rather than becoming missing-control findings.

The Spring Security 7.1 audit then added SEC-RXF-OAUTH2-005 (plain-HTTP OAuth2 client provider endpoints), bringing the catalogue to 26 rules. It also recognizes one-time-token login as interactive browser login and limits the framing and CSP reviews to chains with an observed browser login, so bearer-only API chains no longer receive a CSP finding.

Building the WebFlux-only sample app surfaced a genuine NoClassDefFoundError: BootUiEngineConfiguration.bootUiPentestingScanner() referenced the MVC-only RequestMappingInfoHandlerMapping.class unconditionally in an @Lazy @Bean method body. Resolving that class-literal constant-pool entry throws when spring-webmvc is genuinely absent. Fixed with a ClassUtils.isPresent(...) guard before the .class literal, passing null to SpringPentestingObservationCollector when absent. The collector records that MVC endpoint metadata is unavailable, rather than returning an empty inventory that could be mistaken for inspection finding no mappings. On a mixed MVC/WebFlux classpath, the active application context determines the runtime; MVC classes alone do not enable servlet metadata. The optional-class guard remains before resolving MVC types. Pentesting still evaluates bounded Spring configuration/OAuth metadata plus at most one GET and one OPTIONS loopback response, but A01 servlet coverage is NOT_APPLICABLE and no-finding mixed-category coverage uses WebFlux-specific INFO wording. The reactive Security advisor owns SecurityWebFilterChain, reactive CORS, and route-policy review. The collector uses spring.webflux.base-path for the validated loopback target instead of the servlet-only server.servlet.context-path, and inactive servlet session settings do not produce findings. This is the same defensive pattern the rest of the codebase uses for optional-dependency adapters — the reactive starter was simply the first Spring-side consumer where an MVC type can be genuinely absent from the classpath, not just absent as a bean.

PanelsController unconditionally reported mcp-server and activity as available: true on every platform, even though the reactive autoconfiguration didn't yet wire their controllers. Fixed alongside the other divergent-panel availability checks (§6.5 today). activity has since been genuinely wired reactively (§6.4) and now correctly reports available: true again — this time because a real ReactiveLiveActivityController backs it. Both were caught by WebFluxApiConformanceTest's inherited availablePanelsAnswerTheirPrimaryGet() assertion (§8) — direct evidence for why the conformance suite runs against a real, minimal, single-stack sample app rather than relying on unit tests against a shared multi-stack test classpath alone.

This gap surfaced only through end-to-end testing against the running sample app — unit tests call capture points directly on a single thread, so they never exercise a real Reactor scheduler hop. Stamping Span.current() at each capture point (§6.4) is necessary but not sufficient: Spring Boot 4.1's spring-boot-reactor module only calls Hooks.enableAutomaticContextPropagation() when spring.reactor.context-propagation=auto, and its own default is limited. Under the default, Reactor does not restore OpenTelemetry's ThreadLocal-based span context across the scheduler hops a WebFlux request constantly makes (Netty event loop → boundedElastic/loomBoundedElastic for blocking JDBC → parallel), so Span.current() returned a valid span only by coincidence, on whichever thread a request happened to still be on. Every new trace-stamping capture point read null/an invalid span in practice despite being wired correctly. Fixed by having BootUiActuatorDefaultsEnvironmentPostProcessor contribute spring.reactor.context-propagation=auto as an overridable default whenever the application is reactive and the OpenTelemetry SDK is present. Confirmed by hitting the running sample app directly (/api/notes, /api/sample/boom) and checking /bootui/api/http-exchanges, /bootui/api/sql-trace, /bootui/api/exceptions, and /bootui/api/activity for populated, correctly-nested (parentId) trace ids — none of which a unit test asserts.