-
Notifications
You must be signed in to change notification settings - Fork 701
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#[instrument] - Future-proofing async-trait support in tracing-attributes #1219
Comments
Hmm. IMO, I think instrumenting the outer function and not the returned future is almost never the behavior that users will want, and doing that by default seems like it would be very surprising. In particular, when I'd rather err on the side of making the default do what I think people will want a significant majority of the time — if we're going to add an option to configure the behavior here, I'd make it opt out of instrumenting the returned future. Maybe fn my_fn(arg: Arg) -> Box<dyn Future<...>> {
let span = tracing::info_span!("my_fn", ?arg);
let _e = span.enter();
// ...do stuff inside the span...
Box::new(async move {
// ...outside the span...
})
} |
Thanks for the clarification, you're probably right in that this behavior would be more correct (in the case of a sync function returning a boxed future at least, I'm not sure if there is many uses of functions that do a great deal of work to "prepare" the future, and that the user would want to instrument ?). In any case, if tracing-attributes were to default to instrumenting the returned future, letting the user enter the span manually instead of adding another parameter to |
That would be great! Thanks for working on this. |
…1228) It works with both the old and new version of async-trait (except for one doc test that failed previously, and that works with the new version). One nice thing is that the code is simpler (e.g.g no self renaming to _self, which will enable some simplifications in the future). A minor nitpick is that I disliked the deeply nested pattern matching in get_async_trait_kind (previously: get_async_trait_function), so I "flattened" that a bit. Fixes #1219.
…1228) This backports #1228 from `master` to `v0.1.x`. It works with both the old and new version of async-trait (except for one doc test that failed previously, and that works with the new version). One nice thing is that the code is simpler (e.g.g no self renaming to _self, which will enable some simplifications in the future). A minor nitpick is that I disliked the deeply nested pattern matching in get_async_trait_kind (previously: get_async_trait_function), so I "flattened" that a bit. Fixes #1219.
…1228) (#1291) This backports #1228 from `master` to `v0.1.x`. It works with both the old and new version of async-trait (except for one doc test that failed previously, and that works with the new version). One nice thing is that the code is simpler (e.g.g no self renaming to _self, which will enable some simplifications in the future). A minor nitpick is that I disliked the deeply nested pattern matching in get_async_trait_kind (previously: get_async_trait_function), so I "flattened" that a bit. Fixes #1219. Co-authored-by: Simon THOBY <git@nightmared.fr>
…okio-rs#1228) (tokio-rs#1291) This backports tokio-rs#1228 from `master` to `v0.1.x`. It works with both the old and new version of async-trait (except for one doc test that failed previously, and that works with the new version). One nice thing is that the code is simpler (e.g.g no self renaming to _self, which will enable some simplifications in the future). A minor nitpick is that I disliked the deeply nested pattern matching in get_async_trait_kind (previously: get_async_trait_function), so I "flattened" that a bit. Fixes tokio-rs#1219. Co-authored-by: Simon THOBY <git@nightmared.fr>
Not a bug yet, but
async-trait
is working towards changing the way they wrap an async function in a trait impl (see dtolnay/async-trait#143 for more details).More specifically, they are moving away from a design where they were wrapping the insides of async function into an async function nested inside a "classical" function, and returning the async function, boxing it along the way. Because some code is probably much clearer than anything I can say, this means that the impl of the following code will be translated from:
to something like:
If it can help to demangle my shoddy explanations above, the support for accepting this kind of expressions was added in #711.
The new version would (from what I understand, please correct me if I'm mistaken !) translate the previous code as:
While we could support this code in the same fashion as we support the current version of async-trait, I fear this might lead to some confusion if a user deliberately want to instrument a function returning a future and end up instrumented the future instead. Not quite sure what to do here. Maybe we have to consider adding an argument to the
#[instrument]
macro that would opt-in to instrument the returned closure ?It could be something like:
But that's just some thoughts in the wind :)
Any opinion ?
The text was updated successfully, but these errors were encountered: