open-telemetry / open-telemetry/opentelemetry-java-instrumentation
kotlinx coroutines flow support
Nobody has claimed this yet.
- 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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