Spans unexpectedly remain open within spawned tasks

[joshua-cooper]

What crate(s) in this repo are involved in the problem?

console-subscriber

What is the issue?

When using console-subscriber, spans are kept around across spawned tasks when they wouldn't be without it.

How can the bug be reproduced?

[package]
name = "tc-bug"
version = "0.1.0"
edition = "2021"

[dependencies]
console-subscriber = "0.1.8"
tokio = { version = "1.27.0", features = ["full"] }
tracing = "0.1.37"
tracing-subscriber = "0.3.16"

use std::time::Duration;
use tokio::time::sleep;
use tracing::{info, instrument, metadata::LevelFilter};
use tracing_subscriber::{layer::SubscriberExt, util::SubscriberInitExt, Layer};

#[tokio::main]
async fn main() {
    tracing_subscriber::registry()
        .with(
            tracing_subscriber::fmt::layer()
                .pretty()
                .with_filter(LevelFilter::INFO),
        )
        .with(console_subscriber::spawn()) // comment out this line to see the difference in behavior
        .init();

    fn_a().await;

    sleep(Duration::from_secs(1)).await;
}

#[instrument]
async fn fn_a() {
    info!("hi from a");
    tokio::spawn(fn_b());
}

#[instrument]
async fn fn_b() {
    info!("hi from b");
}

Logs, error output, etc

Without console-subscriber:

  2023-04-20T12:52:30.707451Z  INFO tc_bug: hi from b
    at src/main.rs:30
    in tc_bug::fn_b

With console-subscriber:

  2023-04-20T12:53:33.980546Z  INFO tc_bug: hi from b
    at src/main.rs:30
    in tc_bug::fn_b
    in tc_bug::fn_a

Versions

├── console-subscriber v0.1.8
│   ├── console-api v0.4.0

Possible solution

No response

Additional context

No response

Would you like to work on fixing this bug?

maybe

[hawkw]

This is similar to #345 (comment) --- we should probably change the Tokio instrumentation so that task spans have parent: None, and don't inadvertantly capture the spawning span as their parent...

[hds]

This issue has been fixed in Tokio on master. Since this ticket is a duplicate, I'll close it now. Please refer to #345 to track when the fix has been included in the next Tokio release.