Tracing extension doesn't work properly when used with async code

[ibralu]

Expected Behavior

Should build correct spans tree

Actual Behavior

Inconsistent span trees, some spans are missing parent.
Don't think span.with_subscriber(|(id, d)| d.enter(id)) works in multi threaded runtime

Steps to Reproduce the Problem

1. Clone this repo https://github.com/ibralu/async-graphql-tracing. I've used starwars example with sleep on resolvers
2. Start jaeger

docker run -d --name jaeger \
  -e COLLECTOR_ZIPKIN_HOST_PORT=:9411 \
  -p 5775:5775/udp \
  -p 6831:6831/udp \
  -p 6832:6832/udp \
  -p 5778:5778 \
  -p 16686:16686 \
  -p 14268:14268 \
  -p 14250:14250 \
  -p 9411:9411 \
  jaegertracing/all-in-one:1.22

3. Test with query

{
  hero(episode: EMPIRE) {
    id
    name
    friends {
      id
      name
    }
    appearsIn
  }
}

Specifications

• Version: 2.6
• Platform: macOS
• Subsystem: 11.2

[sunli829]

Thanks for the test, I have fixed it in v2.6.1 version. 🙂

[ibralu]

Thank you for the fix, however, I don't think that would work though, as @D1plo1d has mentioned in #447 we need to wrap the future with instrument
https://github.com/tokio-rs/tracing#in-asynchronous-code

[sunli829]

Thank you for the fix, however, I don't think that would work though, as @D1plo1d has mentioned in #447 we need to wrap the future with instrument
https://github.com/tokio-rs/tracing#in-asynchronous-code

I refer to the code implementation of instrument, in fact it is to call enter repeatedly in different threads.

https://github.com/tokio-rs/tracing/blob/0e8f920d4bc47643d9a035ed2bbe9504ec076ca4/tracing/src/instrument.rs#L148

[sunli829]

Sorry, there still seems to be a problem.

[sunli829]

I still haven't found a solution. 😂

[sunli829]

I am going to switch to opentelemetry, tracing makes me feel very confused.

[sunli829]

I added OpenTelemetry support to the master branch, and it works very well now.
The way tracing works in multithreading is very strange, I decided to give up support for it. @ibralu @D1plo1d

[sunli829]

[D1plo1d]

@sunli829 I'm sorry to hear that. I'm not sure if this helps re: tracing but I think the key to their design is entering the span inside poll and dropping it at the end of poll.

Entering span anywhere else will not work because it will wrap all futures that execute on that thread until it is dropped.

The way they've built it every async thread is only inside the span for the period of a future's poll function - as soon as the poll function returns the drop handler exits the span.

[sunli829]

I think there is no problem with my last modification, but it just doesn't work. This is related to cross-threading.

I ran into the same problem as described here, but the more troublesome thing is that I need a lot of Spans.
tokio-rs/tracing#1188