How do you bridge Reactor Context with ThreadLocal-based libraries like SLF4J MDC for logging trace IDs?

## Why the gap exists **MDC** (Mapped Diagnostic Context, SLF4J/Logback) is a `ThreadLocal<Map>`. Log patterns like `%X{traceId}` read it from the *current thread*. Reactor Context lives on the subscription, not the thread, so on any given thread MDC is empty even though the Context holds the trace ID. Bridging = copying between the two worlds at the right moments. ## Approach 1 — manual bridging with doOnEach `doOnEach` runs a callback for every signal and its `Signal` exposes `getContextView()`. You can populate MDC, log, then clear: ```java flux.doOnEach(signal -> { if (signal.isOnNext()) { String traceId = signal.getContextView().getOrDefault("traceId", "-"); try (MDC.MDCCloseable c = MDC.putCloseable("traceId", traceId)) { log.info("processing {}", signal.get()); } } }); ``` The `try-with-resources`/finally clear is **critical**: WebFlux threads are pooled and long-lived, so a stale MDC entry leaks into unrelated requests. ## Approach 2 — Micrometer context-propagation (the modern way) Since Reactor 3.5 there is first-class integration with the **`io.micrometer:context-propagation`** library: 1. Register a **`ThreadLocalAccessor`** for each ThreadLocal you want bridged (Micrometer Tracing registers accessors for its trace/span ThreadLocals; you can register one that maps an MDC key ⇄ a Context key). 2. Call **`Hooks.enableAutomaticContextPropagation()`** (Reactor) once at startup — Boot's Micrometer Tracing autoconfig can do this. 3. Use **`contextCapture()`** to snapshot current ThreadLocals into the Reactor Context at that point, and Reactor will **restore** the registered ThreadLocals around the execution of downstream operators (so blocking code and logging see them on whatever thread runs). With automatic propagation enabled, imperative-looking code (`MDC.get`, `SecurityContextHolder`) can work inside reactive operators because Reactor restores/clears the ThreadLocals around each operator on each thread. ## Spring integration - **Micrometer Tracing** (the successor to Spring Cloud Sleuth) uses exactly this mechanism to put `traceId`/`spanId` into MDC for WebFlux apps. In Spring Boot 3 you typically just add the tracing starter and a bridge (Brave/OpenTelemetry) and the trace IDs show up in logs. - **Reactive Spring Security** stores `SecurityContext` in Reactor Context via `ReactiveSecurityContextHolder`; the same propagation machinery can expose it to blocking code that reads the classic `SecurityContextHolder`. ## Gotchas and design considerations - **Only registered keys propagate** — automatic propagation isn't magic; each ThreadLocal needs a `ThreadLocalAccessor`. - **Leakage** — always clear ThreadLocals; the framework does this for registered accessors, but manual bridging must clear in a finally block. - **Performance** — restoring ThreadLocals around every operator has a cost; `enableAutomaticContextPropagation` is broad. Scope it and measure. - **Ordering** — the Context must be populated upstream of where the capture/read happens (same upstream-propagation rule as always). - **contextCapture vs contextWrite** — `contextWrite` puts explicit values; `contextCapture()` pulls from currently-registered ThreadLocals into Context automatically. ## When to use which - Small app, one log line: manual `doOnEach` is fine and dependency-free. - Real distributed tracing across many log statements and blocking bridges: adopt Micrometer Tracing + context-propagation rather than hand-rolling.