OpenTelemetry: context of sender not active in consumer

[computerlove]

Describe the bug

When a @ConsumeEventmethod is executed the OpenTelementry context of the sender is not active.
The result of this is that logging MDC, and further calls do not get a tracing context.
Annotating the method with @WithSpan does activate a context, but it is not based on the existing context.
Stepping though the code I can see that the underlying Vert.x Message does have the existing context stored in the tracefield.

Expected behavior

The Opentelemetry context of message sender is active, a new span is created when @WithSpan is used.

Actual behavior

@WithSpan activates a context, but it is not based on the context of the sender.
Without @WithSpan no context is active, and rest client calls does not get a traceid.

How to Reproduce?

A reproducer: https://github.com/computerlove/quarkus-trace-mdc-eventbus
It creates a Thread that first set up a OpenTracing Context, sends a event bus message, which sends a rest request.

Output of uname -a or ver

na

Output of java -version

21

Quarkus version or git rev

3.6.4

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[quarkus-bot]

/cc @brunobat (opentelemetry), @radcortez (opentelemetry)

[gian1200]

I'm also facing this issue (the other way around,: an HTTP Request that uses EventBus to make it async).

However, I'm not sure if it's a bug or an enhancement request. The docs (here and/or here) says that only http requests are supported for quarkus-vertx.

[thomascube]

I stumbled upon the same problem. My way to work around it is to pass Context.current() as a field in the EventBus message and extract it in the receiver:

@ConsumeEvent("TEST-EVENT")
public String testEvent(MyEventObj event) {
    try (var _ = event.getOtelContext().makeCurrent()) {
        // do work
    }
}

Would love to have this implicitly done by the EventBus itself.

[VishnuTeja27]

I faced the same when blocking = true or virtualThread= true.
Existing issue for the same: #41864