-
Notifications
You must be signed in to change notification settings - Fork 754
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
attributes: overriding #[instrument]
target should also effect ret
/err
events
#2183
Labels
crate/attributes
Related to the `tracing-attributes` crate
good first issue
Good for newcomers
kind/bug
Something isn't working
Comments
PR is opened: #2184 |
hawkw
pushed a commit
that referenced
this issue
Jul 1, 2022
## Motivation Currently, when an `#[instrument]` attribute has an overridden target, the events generated by `ret` and `err` arguments do not inherit that target. For example, if I write ```rust #[tracing::instrument(target = "some_target", ret) fn do_stuff() -> Something { // ... } ``` the `do_stuff` span will have the target "some_target", but the return value event generated by `ret` will have the current module path as its target, and there is no way to change the return value event's target. ## Solution This branch changes the macro expansion for `#[instrument]` with the `ret` and/or `err` arguments so that an overridden target is propagated to the events generated by `ret` and `err`. Fixes #2183
hawkw
pushed a commit
that referenced
this issue
Jul 1, 2022
## Motivation Currently, when an `#[instrument]` attribute has an overridden target, the events generated by `ret` and `err` arguments do not inherit that target. For example, if I write ```rust #[tracing::instrument(target = "some_target", ret) fn do_stuff() -> Something { // ... } ``` the `do_stuff` span will have the target "some_target", but the return value event generated by `ret` will have the current module path as its target, and there is no way to change the return value event's target. ## Solution This branch changes the macro expansion for `#[instrument]` with the `ret` and/or `err` arguments so that an overridden target is propagated to the events generated by `ret` and `err`. Fixes #2183
kaffarell
pushed a commit
to kaffarell/tracing
that referenced
this issue
May 22, 2024
…2184) ## Motivation Currently, when an `#[instrument]` attribute has an overridden target, the events generated by `ret` and `err` arguments do not inherit that target. For example, if I write ```rust #[tracing::instrument(target = "some_target", ret) fn do_stuff() -> Something { // ... } ``` the `do_stuff` span will have the target "some_target", but the return value event generated by `ret` will have the current module path as its target, and there is no way to change the return value event's target. ## Solution This branch changes the macro expansion for `#[instrument]` with the `ret` and/or `err` arguments so that an overridden target is propagated to the events generated by `ret` and `err`. Fixes tokio-rs#2183
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
crate/attributes
Related to the `tracing-attributes` crate
good first issue
Good for newcomers
kind/bug
Something isn't working
Currently, when an
#[instrument]
attribute has an overridden target, the events generated byret
anderr
arguments do not inherit that target:tracing/tracing-attributes/src/expand.rs
Lines 203 to 217 in 7a9e1e4
For example, if I write
the
do_stuff
span will have the target "some_target", but the return value event generated byret
will have the current module path as its target, and there is no way to change the return value event's target.We should probably change this so that the overridden target also applies to the events generated by
ret
anderr
. Fortunately, this is probably a pretty straightforward change.See also #2182 (reply in thread)
The text was updated successfully, but these errors were encountered: