Ensure 'res' and 'err' inherit 'target' #2184
Conversation
There was a problem hiding this comment.
this looks good to me, thank you!
it might be nice to add a test; the change is simple enough that I'm sure it works, but adding a test would ensure that future changes don't accidentally break this...
it might also be good to mention in the docs (maybe around here) that the ret and err events inherit the span's target when it is overridden.
|
I would be interested to see how we'd test for this. I know code would need to be added under tests/ret.rs and tests/err.rs, though, I don't know how I'd assert the output would contain the declared target. (On an unrelated note, |
The mock subscriber implementation (in tracing/tracing-attributes/tests/targets.rs Lines 69 to 70 in 7a9e1e4 There's also a function for expecting that an event has a given target. This isn't currently used in tracing/tracing-subscriber/tests/env_filter/main.rs Lines 71 to 72 in de364fb We would essentially just want to write a test similar to the existing tests in Hope that helps, please let me know if you have additional questions! |
Just continue using |
|
Okay, the unit tests have been added! Thanks for the help |
|
Strange how the pipeline failed for that unrelated file @hawkw did you want me to fix this before merging? |
This occurs sometimes when a new release of
Normally we fix these issues separately and then update any failing branches with the latest version of the base branch. In this case, everything should be fixed on |
## 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
## 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
# 0.1.22 (July 1, 2022) This release fixes an issue where using the `err` or `ret` arguments to `#[instrument]` along with an overridden target, such as ```rust #[instrument(target = "...", err, ret)] ``` would not propagate the overridden target to the events generated for errors/return values. ### Fixed - Error and return value events generated by `#[instrument(err)]` or `#[instrument(ret)]` not inheriting an overridden target (#2184) - Incorrect default level in documentation (#2119) Thanks to new contributor @tbraun96 for contributing to this release!
# 0.1.22 (July 1, 2022) This release fixes an issue where using the `err` or `ret` arguments to `#[instrument]` along with an overridden target, such as ```rust #[instrument(target = "...", err, ret)] ``` would not propagate the overridden target to the events generated for errors/return values. ### Fixed - Error and return value events generated by `#[instrument(err)]` or `#[instrument(ret)]` not inheriting an overridden target (#2184) - Incorrect default level in documentation (#2119) Thanks to new contributor @tbraun96 for contributing to this release!
…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
# 0.1.22 (July 1, 2022) This release fixes an issue where using the `err` or `ret` arguments to `#[instrument]` along with an overridden target, such as ```rust #[instrument(target = "...", err, ret)] ``` would not propagate the overridden target to the events generated for errors/return values. ### Fixed - Error and return value events generated by `#[instrument(err)]` or `#[instrument(ret)]` not inheriting an overridden target (tokio-rs#2184) - Incorrect default level in documentation (tokio-rs#2119) Thanks to new contributor @tbraun96 for contributing to this release!
#2182