Errors reported through sentry-tracing have unhelpful titles

[keabarnes]

Environment

Version: 0.36.0

Sentry set up with the sentry-tracing integration.

Steps to Reproduce

1. Followed instructions in the docs to track errors using the tracing macros: https://docs.rs/sentry-tracing/0.36.0/sentry_tracing/#tracking-errors
2. Logged an error along the lines of tracing::error!(error = &custom_error as &dyn Error, "my operation failed - ...");
   1. tried with let custom_error = std::io::Error::new(std::io::ErrorKind::Other, "Custom ioErrorKind Other Error");
   2. tried with custom thiserror based error struct
3. Logged a "control" error using error!("my operation failed - simple error!(\"my operation failed\") has helpful title");

Expected Result

Errors to show up in Sentry with a useful title, either based on the original message, or some version of the error struct name

Actual Result

In the Sentry dashboard, the errors reported using the error = capturing method had titles that had nothing to do with the error but rather referenced the tracing crate. Errors reported without the error = capturing method show up with the message in the title.

[keabarnes]

Added some debug logging inside before_send on the Sentry client.

The code, roughly:

let custom_error = MyError::MyFirstErrorVariant(format!(
    "Testing Error"
));
error!(
    error = &custom_error as &dyn std::error::Error,
    "my operation failed - tracked error is unhelpful 1"
);

The debug log of event from before_send with some stuff ... truncated for brevity:

Event {
    event_id: 41a06b12-023a-4abb-aef6-f1974f746410,
    level: Error,
    fingerprint: [
        "{{ default }}",
    ],
    culprit: None,
    transaction: None,
    message: None,
    logentry: None,
    logger: Some(
        "utils::testing",
    ),
    modules: {},
    platform: "native",
    timestamp: SystemTime {
        tv_sec: 1737988217,
        tv_nsec: 611486000,
    },
    server_name: Some(
        "a765b20e-91fa-3110-b56f-dd6348032988",
    ),
    release: Some(
        "0.1.0",
    ),
    dist: None,
    environment: Some(
        "dev",
    ),
    user: None,
    request: None,
    contexts: {
        "Rust Tracing Location": Other(
            {
                "file": String("/software/src/utils/testing.rs"),
                "line": Number(30),
                "module_path": String("utils::testing"),
            },
        ),
        "device": Device(),
        "os": Os(),
        "rust": Runtime(),
    },
    breadcrumbs: Values {
        values: [...],
    },
    exception: Values {
        values: [
            Exception {
                ty: "MyFirstErrorVariant",
                value: Some(
                    "MyFirstErrorVairant's error message from #[error = ...] on thiserror stuct: Testing Error",
                ),
                module: None,
                stacktrace: None,
                raw_stacktrace: None,
                thread_id: None,
                mechanism: None,
            },
            Exception {
                ty: "tracing::error!",
                value: Some(
                    "my operation failed - tracked error is unhelpful 1",
                ),
                module: Some(
                    "utils::tesing",
                ),
                stacktrace: None,
                raw_stacktrace: None,
                thread_id: None,
                mechanism: Some(
                    Mechanism {
                        ty: "tracing",
                        description: None,
                        help_link: None,
                        handled: None,
                        synthetic: Some(
                            true,
                        ),
                        data: {},
                        meta: MechanismMeta {
                            errno: None,
                            signal: None,
                            mach_exception: None,
                        },
                    },
                ),
            },
        ],
    },
    stacktrace: None,
    template: None,
    threads: Values {
        values: [...],
    },
    tags: {},
    extra: {},
    debug_meta: DebugMeta {
        sdk_info: None,
        images: [],
    },
    sdk: Some(
        ClientSdkInfo {
            name: "sentry.rust",
            version: "0.36.0",
            integrations: [
                "attach-stacktrace",
                "debug-images",
                "contexts",
                "panic",
                "process-stacktrace",
            ],
            packages: [
                ClientSdkPackage {
                    name: "cargo:sentry",
                    version: "0.36.0",
                },
            ],
        },
    ),
}

[keabarnes]

My gut says the part below shouldn't be there, and the value string in it should be put into the top-level event message?

exception.values: [
    ...,
    Exception {
      ty: "tracing::error!",
      value: Some(
          "my operation failed - tracked error is unhelpful 1",
      ),
      module: Some(
          "utils::tesing",
      ),
      stacktrace: None,
      raw_stacktrace: None,
      thread_id: None,
      mechanism: Some(
          Mechanism {
              ty: "tracing",
              description: None,
              help_link: None,
              handled: None,
              synthetic: Some(
                  true,
              ),
              data: {},
              meta: MechanismMeta {
                  errno: None,
                  signal: None,
                  mach_exception: None,
              },
          },
      ),
    },
]

[peter-lockhart-pub]

I also see unhelpful titles <unknown> in 0.36.0. I am running in the context of axum, trying to error trace a handled server error:

event!(
                Level::ERROR,
                error = &self as &dyn Error,
                status = %status,
                "app server error"
            );

[lcian]

@keabarnes The issue title in this case will be determined by the first in-app stack frame you have. Please set in_app_exclude and in_app_include in the client options such that the first in-app frame is meaningful for you.

@peter-lockhart-pub Due to the way we send the event to Sentry, as explained above, it will try to use the top in-app stack frame to determine the title.
You must have attach_stacktraces disabled or the backtrace feature of sentry-tracing disabled, which causes you to have no stack trace and therefore <unknown> to be displayed.
We are going to fix it, however I would recommend you enable stack traces for a better experience.

[peter-lockhart-pub]

@peter-lockhart-pub Due to the way we send the event to Sentry, as explained above, it will try to use the top in-app stack frame to determine the title. You must have attach_stacktraces disabled or the backtrace feature of sentry-tracing disabled, which causes you to have no stack trace and therefore <unknown> to be displayed. We are going to fix it, however I would recommend you enable stack traces for a better experience.

Thanks for that! I have had a look. Yes attach_stracktraces is false because that is what the default is, and I hadn't come across the feature backtrace of sentry-tracing; I don't think it is mentioned in the documentation.

[lcian]

@peter-lockhart-pub Due to the way we send the event to Sentry, as explained above, it will try to use the top in-app stack frame to determine the title. You must have attach_stacktraces disabled or the backtrace feature of sentry-tracing disabled, which causes you to have no stack trace and therefore <unknown> to be displayed. We are going to fix it, however I would recommend you enable stack traces for a better experience.

Thanks for that! I have had a look. Yes attach_stracktraces is false because that is what the default is and I hadn't come across the feature backtrace of sentry-tracing and I don't think it is mentioned in the documentation.

Yeah, I guess we set it off by default because it can be an expensive process, so you need to opt in to it.
sentry-tracing should enable backtrace by default if you also have sentry with the default features so you should just need attach_stacktrace.
We should definitely mention it in the docs.