Skip to content

Ensure tracing gets the correct spawning location for all spawn methods #5038

@hds

Description

@hds

In the recently reported issue #5030 it was identified that tokio console lists a tokio internal location for all tasks created via spawn_local.

Console uses the (as yet unstable) tracing support in tokio to get a task locations via tokio::util::tracing::task. This functionality relies on the #[track_caller] feature.

One caveat of track caller is that it requires an unbroken chain of annotated functions from the calling site to tokio::util::tracing::task and it cannot pass through closures or async functions. This was the cause of the issue reported in #5030, the chain passed through a closure. In the fix for that issue (#5034), access to a thread local variable was refactored to avoid the call stack passing through the closure.

After a discussion on Discord, it seems like it would be good to verify the other cases.

We should go through all the different spawn functions to ensure that the original calling location is passed to tracing. Since ensuring that the call stack all the way up to tokio::util::tracing::task is correctly annotated isn't straight forward, tests should be added similar to those added as part of #4413 to prevent regressions.

The current locations that are calling tokio::util::tracing::task are:

These functions need to be traced back to all the public APIs that call them and those should be verified and tested.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-tokioArea: The main tokio crateM-tracingTracing support in Tokio

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions