Skip to content
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

Closed
hawkw opened this issue Jun 28, 2022 · 1 comment
Closed
Labels
crate/attributes Related to the `tracing-attributes` crate good first issue Good for newcomers kind/bug Something isn't working

Comments

@hawkw
Copy link
Member

hawkw commented Jun 28, 2022

Currently, when an #[instrument] attribute has an overridden target, the events generated by ret and err arguments do not inherit that target:

let err_event = match args.err_mode {
Some(FormatMode::Default) | Some(FormatMode::Display) => {
Some(quote!(tracing::error!(error = %e)))
}
Some(FormatMode::Debug) => Some(quote!(tracing::error!(error = ?e))),
_ => None,
};
let ret_event = match args.ret_mode {
Some(FormatMode::Display) => Some(quote!(tracing::event!(#level, return = %x))),
Some(FormatMode::Default) | Some(FormatMode::Debug) => {
Some(quote!(tracing::event!(#level, return = ?x)))
}
_ => None,
};

For example, if I write

#[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.

We should probably change this so that the overridden target also applies to the events generated by ret and err. Fortunately, this is probably a pretty straightforward change.

See also #2182 (reply in thread)

@hawkw hawkw added kind/bug Something isn't working good first issue Good for newcomers crate/attributes Related to the `tracing-attributes` crate labels Jun 28, 2022
@tbraun96
Copy link
Contributor

PR is opened: #2184

@hawkw hawkw closed this as completed in 63cff14 Jul 1, 2022
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
Projects
None yet
Development

No branches or pull requests

2 participants