OpenTelemetry and event bus with blocking consumer

[danic-wd]

Describe the bug

When using the Vert.x event bus with blocking = true in @ConsumeEvent, the OpenTelemetry context does not get propagated. For example this code:

@ApplicationScoped
public class GreetingService {
    @Inject
    EventBus bus;

    public String greeting(String name) {
        Log.info("Sending greeting: " + name);
        this.bus.send("greeting", name);
        return "hey " + name;
    }

    @ConsumeEvent(value = "greeting", blocking = true)
    void onGreeting(String name) {
        Log.info("Received greeting: " + name);
    }
}

results in:

2024-07-11 12:22:29 INFO  traceId=994c1bec62af95447cb7df534ec2e919, parentId=, spanId=c998018b203816e8 [or.ac.GreetingService] (executor-thread-1) Sending greeting: joe
2024-07-11 12:22:29 INFO  traceId=, parentId=, spanId= [or.ac.GreetingService] (vert.x-worker-thread-21) Received greeting: joe

However, the same code without blocking=true yields:

2024-07-11 12:23:40 INFO  traceId=006987827ab7a89ff4e1ae783e97c8e0, parentId=, spanId=e743768e1c4f15c1 [or.ac.GreetingService] (executor-thread-1) Sending greeting: joe
2024-07-11 12:23:40 INFO  traceId=006987827ab7a89ff4e1ae783e97c8e0, parentId=bddee4bb79082172, spanId=664bb0b413ba2287 [or.ac.GreetingService] (vert.x-eventloop-thread-14) Received greeting: joe

keeping the same traceId as expected. Note that the parentId is wrong in this case as it should match the spanId of the message sender.

If @WithSpan is used then a new traceId is created:

2024-07-11 13:36:20 INFO  traceId=f6ddf7dd419248b49316aeddbc8c3d0a, parentId=, spanId=55857a487db338bc [or.ac.GreetingService] (executor-thread-1) Sending greeting: joe
2024-07-11 13:36:20 INFO  traceId=2e7125b64d0d09b61119e01ef03a0ba2, parentId=, spanId=7bc4db3d048d96e3 [or.ac.GreetingService] (vert.x-worker-thread-39) Received greeting: joe

See also: https://quarkusio.zulipchat.com/#narrow/stream/187030-users/topic/OpenTelemetry.20and.20event.20bus.20with.20blocking.20consumer

Expected behavior

• The OpenTelemetry context is propagated correctly across the event bus.
• Same traceId expected at the receiving end.
• parentId to match the spanId of the sender.
• @WithSpan not to create a new trace.

Actual behavior

• No propagation whatsoever for blocking consumers.
• traceId propagated for non blocking consumers but parentId is wrong.
• When using @WithSpan a new traceId is created.

How to Reproduce?

opentelemetry-quickstart.zip
Steps to reproduce:

• Start the opentelemetry-quickstart service
• Connect to http://localhost:8080/hello from a browser

Output of uname -a or ver

Darwin AC02FW0HAMD6Q 23.5.0 Darwin Kernel Version 23.5.0: Wed May 1 20:09:52 PDT 2024; root:xnu-10063.121.3~5/RELEASE_X86_64 x86_64

Output of java -version

openjdk version "21" 2023-09-19 OpenJDK Runtime Environment Zulu21.28+85-CA (build 21+35) OpenJDK 64-Bit Server VM Zulu21.28+85-CA (build 21+35, mixed mode, sharing)

Quarkus version or git rev

3.12.2

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

Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63) Maven home: /Users/.../.m2/wrapper/dists/apache-maven-3.8.6-bin/67568434/apache-maven-3.8.6 Java version: 21, vendor: Azul Systems, Inc., runtime: /Users/.../.sdkman/candidates/java/21-zulu/zulu-21.jdk/Contents/Home Default locale: en_IE, platform encoding: UTF-8 OS name: "mac os x", version: "14.5", arch: "x86_64", family: "mac"

Additional information

No response

[quarkus-bot]

You added a link to a Zulip discussion, please make sure the description of the issue is comprehensive and doesn't require accessing Zulip

_{This message is automatically generated by a bot.}

[quarkus-bot]

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

[gian1200]

This looks related to #38061

I'd be nice to update the docs (here and/or here) when this is implemented. It currently says that only http requests are supported for quarkus-vertx (which correlates with what I encountered). As per your findings, it looks like it is failing only with blocking = true (same as mine).