Clarification of "RustConf 2019 - Tokio-Trace: Scoped, Structured, Async-Aware Diagnostics by Eliza Weisman"

[EvanCarroll]

In this RustConf 2019 - Tokio-Trace: Scoped, Structured, Async-Aware Diagnostics by Eliza Weisman you can see the author Eliza Weisman hold the _enter guard over an .await this seems to go against the docs,

Warning: in asynchronous code that uses async/await syntax, Span::enter should be used very carefully or avoided entirely. Holding the drop guard returned by Span::enter across .await points will result in incorrect traces.

I may be missing something? Is the example from RustConf 2019 supported?

[hawkw]

Do you mean the example I showed onscreen at 21:52? If you look closely at that code, you'll note that the _enter guard is held in the outer scope (which is synchronous), rather than in the async block itself. The async block is instead instrumented with the Future::instrument combinator before spawning it. The Entered guard itself is never held across an .await, because it's not within the async block itself.

In general, the answer to the question is that it's fine to use Span::enter in any synchronous function, even if they are in a program that also includes async code. That means that if --- as in the example --- we are in a synchronous function that spawns an async block, it's fine to use Span::enter in that function, as long as it's not used in the async block. Similarly, it's always fine to use Span::enter in synchronous functions that are called by an asynchronous function. The issue occurs specifically when the Entered guard is held across an await point, which cannot occur if the enter method is only called in synchronous functions that cannot .await anything.

Hopefully that helps make this a bit clearer; happy to answer any additional questions!