Feature rollbar #37
Feature rollbar #37
Conversation
| std::env::var("ROLLBAR_ACCESS_TOKEN").expect("ROLLBAR_ACCESS_TOKEN env is not set"); | ||
| static ref ROLLBAR_CLIENT: rollbar::Client = | ||
| rollbar::Client::new((*ROLLBAR_ACCESS_TOKEN).clone(), "development".to_owned()); | ||
| static ref LAST_ROLLBAR_THREAD_HANDLE: std::sync::Mutex<Option<std::thread::JoinHandle<Option<ResponseStatus>>>> = |
There was a problem hiding this comment.
to explain this more explicitly. The rollbar library will just start a thread to send the message (so probably not great architecture if there are lots of things rollbar-ing, but hopefully that's not the case, so no worries).
When our application ends, we kill any extant threads. This keeps us alive until the most recently sent rollbar message thread completes (NOTE: this does not ensure all threads will have processed their messages, but I didn't really want to have a thread vec that we need to constantly maintain and check whether things are finished to ensure we're perfect, this seemed like a good middle ground between correct and simple).
| [features] | ||
|
|
||
| # Feature names must not conflict with other package names in the manifest. This is because they are opted into via features = [...], which only has a single namespace. | ||
| with_rollbar = ["rollbar", "backtrace"] |
There was a problem hiding this comment.
Maybe stick something in the readme about this?
mijoharas
force-pushed
the
feature-rollbar
branch
from
cbd682d to
2f6f6ae
Compare
two questions. Firstly, I made rollbar a
featureso you build withcargo build --features rollbar.Also, I want to draw your attention to this which gives me pause: RoxasShadow/rollbar-rs#16 I think it's probably fine though? thoughts?