sentry-rust: Client doesn't log errors

My code is fairly simply, and copying the panic example from the docs doesn’t log anything (nothing shows up on Sentry, and it doesn’t seem to pause to send the events).

//...

#[tokio::main]
async fn main() -> Result<()> {
    let version = env!("VERSION").to_string();
    info!("Version {}", version);

    let sentry = sentry::init((
        "https://XXXXXX@o58074.ingest.sentry.io/YYYYY",
        sentry::ClientOptions {
            release: Some(format!("sync@{}", version).into()),
            ..Default::default()
        },
    ));

    configure_logger();

    if sentry.is_enabled() {
        debug!("Sentry is enabled");
    }

    //...

    panic!("Everything is on fire!");
//...

[2020-08-07 22:42:57] [DEBUG][sync_tool] Sentry is enabled
thread 'main' panicked at 'Everything is on fire!', src/main.rs:165:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

No event on sentry.

Any hints? This is pretty close to a copy-paste from the docs on all sides.

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 1
Comments: 23 (12 by maintainers)

Most upvoted comments

The panic integration is on by default, so sentry::init() should be enough.

Swatinem on Nov 9, 2021

I’m able to reproduce this, but it seems quite random, will investigate.

Swatinem on Aug 21, 2020

I released 0.23.0 recently, which does an explicit flush in the panic handler and will thus work correctly in the panic = "abort" case.

Swatinem on Jul 12, 2021

@ErichDonGubler panic = unwind is probably not the only way to trigger this. A double panic, calling std::process::exit, Arc cyles, or even just calling std::mem::leak could also prevent the necessary drop impls from running.

yaahc on Jan 4, 2021

Ah that is indeed interesting, thanks a lot for investigating this!

And sure thing, when panics abort, the client won’t flush its queue. I wanted to add a flush hook to the transports as well, which we could use unconditionally in the panic handler. I wouldn’t want to close the client completely in the hook, not until cfg(panic = "abort") is stabilized.

Swatinem on Dec 15, 2020

following up on @dconnolly’s messages when I dug into this it seemed to be caused by our panic = abort configuration. I was able to fix it by moving the client drop guard into the panic handler and calling close after reporting a panic.

yaahc on Dec 8, 2020