open-telemetry / open-telemetry/opentelemetry-java-instrumentation

kotlinx coroutines flow support

Open
#8,659 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

bug
Dominant language
Java
Stars
2.6k
Forks
1.2k
Avg merge
2d 18h
Merged PRs (30d)
228

Description

Describe the bug
I am using kotlinx.coroutines.flow to consume messages. The trace ID is not getting propagated down into the consumer as expected. In my use case, I am using a pulsar publisher / consumer / topic.

Steps to reproduce
I have coded this into a repo with README steps to follow: https://github.com/damienburke/pulsar-otel

What did you expect to see?
Via auto instrumentation and setting the extension function io.opentelemetry.extension.kotlin.asContextElement I would expect the same traceId by injected into the spans: send, receive, process and the manually instrumented consumer spans

What did you see instead?
An auto generated send and receive span. Consumer spans for my manual instrumentation. The send and receive spans have the same traceId. The consumer spans have a different trace ID. (No process span created either)

What version are you using?
1.26.0

Environment
Docker. Non-prod currently.

Additional context
When using a basic consumer (i.e. no coroutine or flow code), the traceIds get propagated as expected. This is coded in the repo also. I can find no docs on this, so not sure if this should work, but assume it should due to https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/instrumentation/kotlinx-coroutines

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the README and reproduction repository at https://github.com/damienburke/pulsar-otel, comparing its basic consumer with the kotlinx.coroutines.flow case. Then inspect the kotlinx-coroutines instrumentation and the use of io.opentelemetry.extension.kotlin.asContextElement. Done means the consumer spans share the expected trace ID and a process span is created for the coroutine-based flow.

Written by the indexing model from the issue text.

Assessment

Tech stack
java, kotlin
Domain
distributed-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.