Sentry client doesn't send events in v0.22.0

[onelson]

I see there are already several tickets open regarding "sentry doesn't send events" but they cite different versions of the sdk and seem to be related to different causes. This may very well be a duplicate -- I'm unsure.

I've got an actix-web (3.x.x) app and I'm trying to follow along with the examples in the docs to add sentry support.

Environment

In my Cargo.toml

[dependencies.sentry]
version = "0.22.0"
features = [
    "anyhow",
    "log",
    "debug-logs",
]

[dependencies.sentry-actix]
version = "0.22.0"

In my main.rs:

#[actix_web::main]
async fn main() -> Result<()> {
    #[cfg(feature = "dotenv")]
    dotenv::dotenv().ok();

    env_logger::init();

    let _guard = sentry::init((
        dbg!(std::env::var("SENTRY_DSN").unwrap_or_default()),
        sentry::ClientOptions {
            release: sentry::release_name!(),
            ..Default::default()
        },
    ));
    std::env::set_var("RUST_BACKTRACE", "1");

    log::error!("smoke test");

// ...

    log::info!("Server starting on `{}`", bind_addr);

    Ok(HttpServer::new(move || {
        App::new()
            .wrap(middleware::Logger::default())
            .wrap(sentry_actix::Sentry::new())
            .configure(handlers::configure_routes)
    })
    .bind(bind_addr)?
    .run()
    .await?)
}

Steps to Reproduce

Starting the service, and making a request to a handler like:

#[get("/whoops")]
pub async fn whoops(_req: HttpRequest) -> crate::Result<&'static str> {
    Err(std::io::Error::new(std::io::ErrorKind::Other, "smoke test").into())
}

Expected Result

2 new issues arriving in my sentry project

• the log::error!("smoke test"); in main, and
• the Err returned by the handler.

Actual Result

Neither issue made it through to sentry.

web    | [2021-06-16T18:01:27Z DEBUG sentry::transport] spawning reqwest transport
web    | [2021-06-16T18:01:27Z DEBUG sentry::init] enabled sentry client for DSN https://xxxx.sentry.io/api/0000
web    | [2021-06-16T18:01:27Z ERROR chibi_cerebro] smoke test
web    | [2021-06-16T18:01:27Z INFO  chibi_cerebro] Server starting on `0.0.0.0:7878`
web    | [2021-06-16T18:03:13Z INFO  actix_web::middleware::logger] 127.0.0.1:37306 "GET /whoops HTTP/1.1" 500 36 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.101 Safari/537.36" 0.000692
web    | [2021-06-16T18:03:13Z DEBUG sentry::transport] Sending envelope
web    | [2021-06-16T18:03:13Z DEBUG sentry::transport] Failed to send envelope: error sending request for url (https://xxxx.sentry.io/api/0000/envelope/): error trying to connect: invalid certificate: UnknownIssuer

I notice there was no failure reported by the sentry crate for the log crate usage, so I assume the log feature just isn't working for some reason.

The request to the endpoint caused sentry to log a cert validation error.

---

I've additionally started to experiment with different transports to see if one might magically work as expected, but so far I've not had any luck.

For example, I get the same result with:

[dependencies.sentry]
version = "0.22.0"
default-features = false
features = [
    "backtrace", "contexts", "panic",

    "anyhow",
    "log",
    "debug-logs",
    # override the default transport
    "reqwest",
    "rustls",
]

N.B. The docs talk about an env_logger feature, which appears to have been removed in 0.22.0.

[onelson]

Having cycled through:

• transport (the default, reqwest w/ native-tls)
• curl
• surf
• reqwest w/ rustls

surf was the only transport that actually worked. The rest failed similarly through they reported their errors in their own way.

For example, curl gave:

web    | [2021-06-16T18:36:51Z DEBUG sentry::init] enabled sentry client for DSN https://xxxx.sentry.io/api/0000
web    | [2021-06-16T18:36:51Z ERROR chibi_cerebro] smoke test
web    | [2021-06-16T18:36:51Z DEBUG sentry::transport] spawning curl transport
web    | [2021-06-16T18:36:51Z INFO  chibi_cerebro] Server starting on `0.0.0.0:7878`
web    | [2021-06-16T18:37:03Z INFO  actix_web::middleware::logger] 127.0.0.1:37802 "GET /whoops HTTP/1.1" 500 36 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.101 Safari/537.36" 0.000487
web    | [2021-06-16T18:37:03Z DEBUG sentry::transport] curl: > CONNECT xxxx.sentry.io:443 HTTP/1.1
web    |     Host: xxxx.sentry.io:443
web    |     Proxy-Connection: Keep-Alive
web    | [2021-06-16T18:37:03Z DEBUG sentry::transport] curl: < HTTP/1.1 200 Connection established
web    | [2021-06-16T18:37:03Z DEBUG sentry::transport] curl: < 
web    | [2021-06-16T18:37:03Z DEBUG sentry::transport] Failed to send event

While the surf transport was able to send the Err from my handler, it still didn't capture the log::error!() usage.

[aramperes]

error trying to connect: invalid certificate: UnknownIssuer

Are you running this in Docker? If so you'll need to install the ca-certificates package (Debian) or another similar package that contains the root certs needed for the HTTPS connection.

[onelson]

I will be deploying in docker, but no. This is on my ubuntu workstation, real metal, no containers or virtualization.

[onelson]

WRT: the log integration. It appears some additional setup is required. Coming from an env_logger setup, I had to do:

let mut log_builder = env_logger::Builder::from_default_env();
let logger = sentry::integrations::log::SentryLogger::with_dest(log_builder.build());
log::set_boxed_logger(Box::new(logger)).unwrap();
log::set_max_level(log::LevelFilter::Info);

I don't know. It might be nice to note which features just work by default with the list of features on the front page of the docs, also noting which ones require extra steps.

[aramperes]

For what it's worth, I have the same setup for env_logger, and it's pretty clear to me that it doesn't "just work" without any configs based on the readme: https://github.com/getsentry/sentry-rust/tree/master/sentry-log#examples. Perhaps it could have better instructions on top of the example.

Circling back to the original issue, the biggest hint IMO is the error I highlighted (error trying to connect: invalid certificate: UnknownIssuer). I don't know of a way to get more info about this, but off the top of my head it could be because of a corporate proxy, or some other missing SSL configuration. In my case, I only encountered this when I was running in Docker (and missing the root CA certs, hence my previous question). I'm also using Ubuntu on bare-metal and not running into this.

Hopefully someone else can pitch on this.

[onelson]

For what it's worth, I have the same setup for env_logger, and it's pretty clear to me that it doesn't "just work" without any configs based on the readme: https://github.com/getsentry/sentry-rust/tree/master/sentry-log#examples.

The thing of it is, I never saw this readme until some time later since my entry point to the docs was the sentry crate itself and nothing urged me to look at docs for other crates. Since the sentry-log crate is re-exported from the main sentry crate I didn't even know to go looking.

[onelson]

RE: the SSL configuration. Is there anything particularly distinct in the surf transport code that would make it work where the others fail?

There's no corporate proxy in play (that I'm aware of) but we do install our own root cert on our machines. This is done with update-ca-certificates in the usual way. 🤷

[Swatinem]

Hi @onelson , have you reached any new conclusions here? From your log, it really looks like rather a SSL/system related problem?

[onelson]

No new conclusions. You asked about the system I ran the tracing repo on in #180, and in that case I was working on my corporate-furnished Centos7 workstation. The common thread between these systems might be the CA cert we use for the corporate domain.

I did notice I didn't have to configure surf as the transport for services that ran in our set of base docker images (debian stretch) which include our CA, so perhaps it's not just the CA itself.

Not sure where to look next.

[onelson]

So, over on the tracing topic, I was able to send events to sentry.io from my home machine as of 0.23 using the default transport, so I guess this is either no longer an issue with the sdk upgrade, or via system updates, or I don't know what.

Thanks for your attention! 😅