Context
Currently the API allows us to provide a SPI implementation to decorate the outbound HTTP request via HttpRequestDecorator implementation.
The problem
HttpExecutor dispatches the request build + send onto WorkflowApplication.executorService(), and a workflow may hop threads several times befora a task runs. By example, with you add a wait task first and use a http task after it is impossible for HttpRequestDecorator to read any thread-bound context that only exists on the thread that called WorkflowInstance.start()
2026-06-23 16:06:50,158 INFO [io.quarkiverse.flow.tracing.TraceLoggerExecutionListener] (executor-thread-1) Task 'wait-0' started at 2026-06-23T16:06:50.158432-03:00 pos=do/0/wait-0
2026-06-23 16:06:53,162 INFO [io.quarkiverse.flow.tracing.TraceLoggerExecutionListener] (ForkJoinPool.commonPool-delayScheduler) Task 'wait-0' completed at 2026-06-23T16:06:53.162152-03:00 output={}
2026-06-23 16:06:53,164 INFO [io.quarkiverse.flow.tracing.TraceLoggerExecutionListener] (ForkJoinPool.commonPool-delayScheduler) Task 'http-1' started at 2026-06-23T16:06:53.164578-03:00 pos=do/1/http-1FAIL: The HttpRequestDecorator does not have access to the thread context (it executes in ForkJoinPool.commonPool-delayScheduler) the caller one is the executor-thread-1.
Details: When the http task is the first one it is called with the same thread that called the WorkflowApplication.start():
2026-06-23 16:17:29,312 INFO [io.quarkiverse.flow.tracing.TraceLoggerExecutionListener] (executor-thread-1) Workflow name=backend-call instanceId=01KVTYMTX84Y5W37DKED7ZE637 started at 2026-06-23T16:17:29.311957-03:00 input={}
2026-06-23 16:17:29,313 INFO [io.quarkiverse.flow.tracing.TraceLoggerExecutionListener] (executor-thread-1) Task 'http-0' started at 2026-06-23T16:17:29.313316-03:00 pos=do/0/http-0OK: The HttpRequestDecorator does have access to the thread context and be able to run the tasks with the captured context.
Proposal
A SPI in impl/core to allow us to capture the context of the caller thread.
Context
Currently the API allows us to provide a SPI implementation to decorate the outbound HTTP request via
HttpRequestDecoratorimplementation.The problem
HttpExecutordispatches the request build + send ontoWorkflowApplication.executorService(), and a workflow may hop threads several times befora a task runs. By example, with you add awaittask first and use ahttptask after it is impossible forHttpRequestDecoratorto read any thread-bound context that only exists on the thread that calledWorkflowInstance.start()FAIL: The
HttpRequestDecoratordoes not have access to the thread context (it executes inForkJoinPool.commonPool-delayScheduler) the caller one is theexecutor-thread-1.Details: When the
httptask is the first one it is called with the same thread that called theWorkflowApplication.start():2026-06-23 16:17:29,312 INFO [io.quarkiverse.flow.tracing.TraceLoggerExecutionListener] (executor-thread-1) Workflow name=backend-call instanceId=01KVTYMTX84Y5W37DKED7ZE637 started at 2026-06-23T16:17:29.311957-03:00 input={} 2026-06-23 16:17:29,313 INFO [io.quarkiverse.flow.tracing.TraceLoggerExecutionListener] (executor-thread-1) Task 'http-0' started at 2026-06-23T16:17:29.313316-03:00 pos=do/0/http-0OK: The
HttpRequestDecoratordoes have access to the thread context and be able to run the tasks with the captured context.Proposal
A SPI in
impl/coreto allow us to capture the context of the caller thread.