hyper-util tracing behavior leads to very surprising behavior for client code

[mattklein123]

Version

hyper-util latest

Platform

all

Summary

See tokio-rs/tracing#3521 for full context.

The TL/DR is that https://github.com/hyperium/hyper-util/blob/8ae9e8b1e338a5b7d35155a0dc3708cfd94bcae2/src/rt/tokio.rs#L110-L112 leads to very difficult to debug behavior via the executor spawning a task inside the current span where that task may be very long lived (like a connection pool connection).

I'm happy to make changes here but I wanted to understand what the maintainers would like to do. IMHO the tracing feature is broken and shouldn't work like this. It seems bad to just spawn with the current Span onto a new task.

My initial take is to just remove the code/feature entirely until someone wants to improve it. Alternatively I think it has to be changed so that tracing is opt-in per request somehow.

Thoughts and guidance?

Code Sample

Expected Behavior

Don't capture the current Span onto a long lived background task.

Actual Behavior

Spans are captured onto a long lived background task.

Additional Context

No response

[seanmonstar]

I've seen both sides argued. Personally, I lean more towards fixing this behavior than keeping the current behavior. But more is in #3904 (perhaps even this being a duplicate?).