Comments (26)
Using #[tokio::main]
may be the issue. We're currently updating our documentation to explain why that shouldn't be done and what to do instead. The problem is that sentry::init
must be called before the async
runtime is started, but #[tokio::main]
prevents that.
Can you rewrite main to a form like this?
fn main() {
let _guard = sentry::init((
"my dsn",
ClientOptions {
release: sentry::release_name!(),
environment: Some(secrets.environment.to_string().into()),
sample_rate: secrets.sentry_sample_rate.parse::<f32>().unwrap_or(0.0),
..Default::default()
},
));
let logger = sentry_log::SentryLogger::with_dest(env_logger::builder().build());
log::set_boxed_logger(Box::new(logger)).unwrap();
log::set_max_level(secrets.log_level.clone().into());
tokio::runtime::Builder::new_multi_thread()
.enable_all()
.build()
.unwrap()
.block_on(async {
// the rest of main
});
}
from sentry-rust.
Thank you for the report, we will look into it as soon as possible.
from sentry-rust.
Is the code excerpt from your main
function? Are you using #[tokio::main]
or something similar?
from sentry-rust.
yes, we are using tokio
from sentry-rust.
Is the code excerpt from your
main
function? Are you using#[tokio::main]
or something similar?
just to further clarify for additional help. This is from main and we are using tokio::main
to init the runtime. The only code that runs prior to the initial sentry configuration is fetching our secrets (so we can configure sentry programmatically). The guard stays in scope for the entire lifetime of the application. Main proceeds to call another function that starts up the rest of the application.
Due to our code not being opensource I'm unable to share snippets beyond our sentry configuration
from sentry-rust.
This might be problematic as the way we fetch secrets needs to be async as we are leveraging a library that uses async/await. In the past we've solved this with block_on
however this seems to be causing more issues when I remove the tokio::main
macro.
thread 'main' panicked at 'there is no reactor running, must be called from the context of a Tokio 1.x runtime'
So now we have an issue where we can't use a macro to start the tokio runtime, but we need the tokio runtime before we fetch secrets to pass them to sentry..
from sentry-rust.
Can you extract your business logic (whatever follows sentry::init
) into an async function and call it from main
?
from sentry-rust.
we're already doing that for the most part. Main fetches secrets, starts sentry, initializes some dependencies, and calls an async start_xxx
function which contains the core logic
Everything after sentry init is now wrapped in the runtime you provided above, which compiles, but panics at runtime with the error above in the logic that fetches our secrets to initialize sentry
from sentry-rust.
revisiting as issue still isn't resolved. @loewenheim I have implemented main
as you have stated and extracted the rest of the logic after sentry configuration into start
. Main now looks like the following without #[tokio::main]
fn main() {
let secrets = secrets::fetch();
env_logger::builder()
.filter_level(secrets.log_level.clone().into())
.init();
let _guard = sentry::init((
"redacted dsn",
ClientOptions {
release: sentry::release_name!(),
environment: Some(secrets.environment.to_string().into()),
sample_rate: secrets.sentry_sample_rate.parse::<f32>().unwrap_or(0.0),
..Default::default()
},
));
sentry::configure_scope(|scope| {
scope.set_tag("redacted key", "redacted value")
});
_ = tokio::runtime::Builder::new_multi_thread()
.enable_all()
.build()
.unwrap()
.block_on(async { start(&secrets).await });
}
Issue still occurs. At the beginning of start()
I have added an info, warn, and error log but do not show up in sentry.
from sentry-rust.
Do you have any debug-level logs of your app?
from sentry-rust.
Specifically, logs of Sentry when running with the debug: true
option.
from sentry-rust.
With debug true and start()
only containing the following code
async fn start(secrets: &VaultSecrets) {
info!("this should be a breadcrumb");
warn!("testing rust sentry runtime");
error!("testing rust sentry runtime");
}
outputs:
[sentry] enabled sentry client for DSN <correct dsn>
[2023-09-05T13:40:01Z INFO redacted] this should be a breadcrumb
[2023-09-05T13:40:01Z WARN redacted] testing rust sentry runtime
[2023-09-05T13:40:01Z ERROR redacted] testing rust sentry runtime
[sentry] dropping client guard -> disposing client
[sentry] client close; request transport to shut down
from sentry-rust.
Indeed the SDK does not report any attempt to capture / send an event.
To further narrow this problem down, can you:
- use both
tracing::error!
as well assentry::capture_message
, to know if there is an issue with the tracing integration, or if we have a problem with normal event sending. - do both also before starting the async runtime.
I see you are using sample_rate: secrets.sentry_sample_rate.parse::<f32>().unwrap_or(0.0),
. Are you absolutely certain you are actually sampling some events? If in doubt, please remove that explicit setting so we are confident that the SDK is capturing all events.
from sentry-rust.
I see you are using
sample_rate: secrets.sentry_sample_rate.parse::<f32>().unwrap_or(0.0),
. Are you absolutely certain you are actually sampling some events? If in doubt, please remove that explicit setting so we are confident that the SDK is capturing all events.
The code that fetches these values is tested pretty thoroughly and is running in our production environment, but for sanity checking, I've replaced this with 1.0
. The default of 0.0
doesnt make sense here.
- use both
tracing::error!
We're not using tracing (yet), we are using env_logger
per the crate documentation. Could this be the reason? I've also added the capture_message
and those appear in sentry before and after the runtime is initialized. We have known this works since we are using the anyhow
integration.
Here's the output from the run with the new logs
[2023-09-06T13:35:15Z ERROR] testing sentry error before tokio runtime
[2023-09-06T13:35:15Z INFO] this should be a breadcrumb
[2023-09-06T13:35:15Z WARN] testing rust sentry runtime
[2023-09-06T13:35:15Z ERROR] testing rust sentry runtime
[sentry] dropping client guard -> disposing client
[sentry] client close; request transport to shut down
[sentry] Get response: `{"id":"7670..."}`
[sentry] Get response: `{"id":"c9ee..."}`
from sentry-rust.
Thanks for clearing up the confusion here, and good to see that there is no problem with normal capture_message
calls.
So indeed this seems to be something going wrong with the env logger / log integration. I can have a closer look at this soon.
from sentry-rust.
Thanks for clearing up the confusion here, and good to see that there is no problem with normal
capture_message
calls.
No problem, all the info helps when debugging something like this
I can have a closer look at this soon.
Appreciate it, hopefully this is something simple. Thanks for looking into this
from sentry-rust.
I have been looking into this problem again, and I believe this to be a very trivial version mismatch.
If you indeed still have the following in your Cargo.toml
according to your original comment:
sentry = { version = "0.30.0", features = ["anyhow"] }
sentry-log = "0.31.5"
Then this version mismatch might be the problem. Rust supports having multiple versions of the same crate compiled in one executable. sentry-log
is outputting things into [email protected]
which is not initialized. [email protected]
is the one that is initialized, and which is thus also used by sentry-anyhow
.
Trying different snippets, this wonβt work as it does not include the sentry log integration / sink:
env_logger::builder()
.filter_level(secrets.log_level.clone().into())
.init();
Using the following snippet, I can get error!
to sentry without a problem, the info!
and warn!
turn into breadcrumbs by default.
In hindsight, splitting the SDK up into multiple crates was a mistake, as this is not the first time people (including myself) have run into problems related to version mismatches.
from sentry-rust.
Using the following snippet
What is the following snippet? I've bumped the sentry crate version to match the sentry-log version and still do not get the errors or breadcrumbs
from sentry-rust.
π looks like I never copy-pasted that, and I also reverted it from my working tree.
Does it also have matching versions in the Cargo.lock
file? I remember that some mismatches might slip through that way as well.
from sentry-rust.
Ok so some information was left out on my end and I apologize for that. We're using a workspace and I was using one of these runners as a guinnea pig. Found that we were still using an older sentry version to match the other runners and sentry-log was still mismatched. I've fixed this by bumping the other versions in the other runners and instead of version 0.31.5
, its installing to version 0.31.7
despite the patch version being specified as 5. Ran it, still didnt show up in web interface. I then used the workspace to specify dependencies, cleared the cargo lock, re-built, saw the 0.31.7 version was built again, ran the same consumer, but this time I get the error below.
thread 'main' panicked at 'sentry crate was compiled without transport', /$HOME/.cargo/registry/src/github.com-1ecc6299db9ec823/sentry-0.31.7/src/transports/mod.rs:99:13
from sentry-rust.
π looks like I never copy-pasted that, and I also reverted it from my working tree.
unfortunate
Does it also have matching versions in the
Cargo.lock
file? I remember that some mismatches might slip through that way as well.
with the above I've ensured that the package versions are the same
from sentry-rust.
The above panic is still pointing towards some kind of crate versioning or dependency problem. Iβm unsure how to further help here?
from sentry-rust.
it doesn't seem to be a version mismatch here. I've downgraded to 0.30.0 and still nothing even though all dependencies are the same version. Am I missing something with the integration? It should just work right?I haven't changed any of the sentry configuration from above
from sentry-rust.
Yes, starting up sentry itself, and then setting the SentryLogger which forwards things to its configured destination, that should work ideally.
from sentry-rust.
Resolved and was able to figure it out. It was a version mismatch. I feel like this issue has a couple of takeaways in terms of documentation fixes that should be done. Thanks a bunch for the help all.
from sentry-rust.
Thanks for taking another look, this is helpful.
As I mentioned previously, in hindsight, splitting up the SDK into multiple sub-crates was a mistake, and I would probably merge these all into a single crate once again if/when we are making another bigger refactor of things.
from sentry-rust.
Related Issues (20)
- Not getting PII even though send_default_pii is set to true HOT 1
- Use `ClientOption::send_default_pii` everywhere
- std::backtrace compatibility HOT 4
- Corrupted documentation in actix-web online guide HOT 8
- Streamline and align the "Getting Started" docs to fit in the new structure
- Distributed tracing of outgoing request HOT 1
- `cargo audit` fails on `sentry` due to transitive dependency `webpki` HOT 1
- Does `traces_sample_rate` affect breadcrumb reporting from `tracing::info`? HOT 3
- Error events can silently be lost HOT 2
- Breadcrumbs from Multiple Requests Mixing in Sentry Traces HOT 3
- Propagate tracing span attributes in sentry events HOT 3
- Improve the ability to debug sentry integration HOT 1
- Unable to add a breadcrumb from actix-web middleware
- Can I get a backtrace from an `Event`? HOT 1
- sentry-tracing: `SentryLayer` ignores `event_filter` if `event_mapper` is set HOT 3
- tracing: Propagate span to tags HOT 1
- Question: is there a way to set up automatic performance monitoring transaction for each incoming request for Tonic HOT 4
- Sentry client does not flush metrics unless bound to a hub HOT 2
- Metric::parse_statsd does not roundtrip with gauges HOT 8
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sentry-rust.