Transparent contextCapture in block operators #3420
Conversation
chemicL
added
type/enhancement
Operators that block to retrieve the result from the reactive chain are usually used in imperative contexts. If `ThreadLocal` values are present at call site, they can be captured automatically. This change frees the user from calling `contextCapture` everywhere that they block. The following operators were altered to capture automatically if the context-propagation library is on the classpath: * `Mono#block`, * `Mono#blockOptional`, * `Flux#blockFirst`, * `Flux#blockLast`, * `Flux#toIterable`. Fixes #3406.
chemicL
force-pushed
the
auto-capture-in-block
branch
from
26c5b48
to
911aa2e
Compare
|
@chemicL thanks a lot for this PR. It will be great if this can be merged soon, as I am migrating our codebase to spring boot 3 and without this, I will have to add |
There was a problem hiding this comment.
I like that this behavior is connected with the enableAutomaticContextPropagation hook. I'm wondering whether a separate autoCaptureInBlock flag is even needed to start?
Arguably making ThreadLocal values available automatically throughout the chain goes along with capturing automatically at the start of the chain. So unless we have something specific in mind, I can suggest dropping the extra flag for now. We can always add it later if the need arises. At that point it may be more clear whether it should be a boolean, or a key predicate, or a function of some sort that provides extra control.
Operators that block to retrieve the result from the reactive chain are usually used in imperative contexts. If
ThreadLocalvalues are present at call site, they can be captured automatically. This change frees the user from callingcontextCaptureeverywhere that they block.The following operators were altered to capture automatically if the context-propagation library is on the classpath:
Mono#block,Mono#blockOptional,Flux#blockFirst,Flux#blockLast,Flux#toIterable.Fixes #3406.