Redis OpenTelemetry spans create new traces when using a custom SmallRye ManagedExecutor (Quarkus 3.37.2)

[GUMMADAPUSURESH]

Redis OpenTelemetry spans create new traces when using a custom SmallRye ManagedExecutor (Quarkus 3.37.2)

Hi everyone,

I'm seeing unexpected OpenTelemetry tracing behavior with the Quarkus Redis client when using a custom ManagedExecutor.

Environment

• Quarkus: 3.37.2
• Java: 25
• OpenTelemetry: quarkus-opentelemetry
• Context Propagation: quarkus-smallrye-context-propagation
• Redis: quarkus-redis-client
• Jaeger as the tracing backend

Scenario

I execute two asynchronous tasks using CompletableFuture:

• Persist data to MongoDB
• Update Redis cache

Both tasks are executed using a ManagedExecutor.

Custom ManagedExecutor

@ApplicationScoped
public class VirtualExecutorProducer {

    private final ExecutorService executor =
            Executors.newVirtualThreadPerTaskExecutor();

    @Produces
    @VirtualThreadsManaged
    public ManagedExecutor createManagedExecutor() {
        return SmallRyeManagedExecutor.builder()
                .withExecutorService(executor)
                .propagated(ThreadContext.ALL_REMAINING)
                .build();
    }
}

I also reproduced the same behavior using:

Executors.newFixedThreadPool(...)

instead of virtual threads, so the issue does not appear to be specific to virtual threads.

Async execution

CompletableFuture<Void> redisFuture = managedExecutor.runAsync(() ->
    configurationRedisService.set(...)
);

CompletableFuture<Void> mongoFuture = managedExecutor.runAsync(() ->
    repository.persist(...)
);

CompletableFuture.allOf(redisFuture, mongoFuture).join();

Observations

Inside the async task:

• Span.current().getSpanContext().isValid() is true
• Span.current().getSpanContext().getTraceId() matches the HTTP request trace
• MDC also contains the correct traceId

Example:

Log.infof(
    "traceId=%s spanId=%s",
    Span.current().getSpanContext().getTraceId(),
    Span.current().getSpanContext().getSpanId()
);

valueCommands.set(redisKey, value);

Log.infof(
    "traceId=%s spanId=%s",
    Span.current().getSpanContext().getTraceId(),
    Span.current().getSpanContext().getSpanId()
);

The trace ID remains the same before and after the Redis call.

Expected behavior

The Redis CLIENT span should be a child of the current HTTP request span.

Actual behavior

In Jaeger:

• The HTTP request appears as a single trace.
• Redis GET, SET, and EXPIRE operations each appear as completely separate traces with their own trace IDs when using the custom ManagedExecutor.
• REST Client spans are correctly attached to the parent HTTP trace.
• MongoDB operations are not instrumented in my application, regardless of whether I use the default injected ManagedExecutor or my custom one, so I cannot compare MongoDB tracing behavior.

Additional observations

• If I inject the default Quarkus ManagedExecutor:

@Inject
ManagedExecutor managedExecutor;

Redis spans are correctly linked to the parent HTTP request trace.

• If I produce my own SmallRyeManagedExecutor, the active OpenTelemetry context is still correct:

  • Span.current() contains the expected trace ID.
  • MDC contains the expected trace ID.
  • Context propagation appears to be working.

• Despite this, Redis CLIENT spans are emitted as independent root traces.

• I verified the same behavior with both:

  • Executors.newVirtualThreadPerTaskExecutor()
  • Executors.newFixedThreadPool(...)

  Therefore, the issue does not appear to be related to virtual threads themselves.

Question

Is this expected behavior when creating a custom SmallRyeManagedExecutor using SmallRyeManagedExecutor.builder().withExecutorService(...), or is this a limitation/bug in the Quarkus Redis OpenTelemetry instrumentation?

Has anyone encountered this before or knows if there is an officially supported way to use a custom ManagedExecutor (or a custom ExecutorService) while preserving Redis tracing?

[cescoffier]

I don't think you can use such a kind of executor with virtual threads. You need to use the proposed one that propagates the duplicated context. Did you try with the Quarkus virtual thread executor?

[GUMMADAPUSURESH]

Thanks. I haven't tried the Quarkus virtual thread executor yet.

One thing that confused me is that the OpenTelemetry context appears to be propagated correctly with my custom SmallRyeManagedExecutor:
Span.current() is valid
the traceId matches the incoming HTTP request
MDC also contains the expected traceId

However, Redis CLIENT spans are still exported as independent root traces, while REST Client spans are correctly attached to the parent trace.

Since the same behavior occurs with both newVirtualThreadPerTaskExecutor() and newFixedThreadPool(), it seems related to the custom ManagedExecutor itself rather than virtual threads.

I'll try reproducing it with the Quarkus-provided virtual thread executor. Is the expectation that extensions such as Redis require the Quarkus-managed executor because they depend on the duplicated Vert.x context in addition to the OpenTelemetry context?

[GUMMADAPUSURESH]

Thanks for the clarification and the detailed explanation.

I've managed to achieve the desired behavior by using the Quarkus-managed virtual thread executor instead of creating my own ExecutorService via Executors.newVirtualThreadPerTaskExecutor().

Using the Quarkus-provided @VirtualThreads ExecutorService preserves the tracing behavior correctly, and Redis spans are now properly linked to the parent request trace.

@ApplicationScoped
public class VirtualExecutorProducer {

    private final ExecutorService quarkusVirtualExecutor;

    public VirtualExecutorProducer(@VirtualThreads ExecutorService quarkusVirtualExecutor) {
        this.quarkusVirtualExecutor = quarkusVirtualExecutor;
    }

    @Produces
    @VirtualThreadsManaged // Custom CDI qualifier
    public ManagedExecutor createVirtualManagedExecutor() {
        return SmallRyeManagedExecutor.builder()
                .withExecutorService(quarkusVirtualExecutor)
                .propagated(ThreadContext.ALL_REMAINING)
                .build();
    }
}