roxasshadow / rollbar-rs

Track and report errors, exceptions and messages from your Rust application to Rollbar.

rollbar-rs

Track and report errors, exceptions and messages from your Rust application to Rollbar.

Usage

Automatic logging

examples/panic.rs will show you how to set a hook for all the panics that your application could raise so that they will be handled automatically by rollbar-rs in order to be tracked on Rollbar.

You can run it with $ cargo run --example panic if you remember to set the correct access_token.

Manual logging

Manual logging could be useful when you want to handle errors in your application but also notify Rollbar about them.

examples/error.rs shows how to deal with errors, while examples/message.rs is for plain text reports.

Customize the reports

Check the documentation to understand how you can add or modify one or more fields in the reports that will be sent to Rollbar. Generally, all the methods whose names starts with with_ or from_ is what you need.

rollbar-rs's Issues

"dispatch dropped without returning error"

I believe we're running into a manifestation of this panic in hyper: hyperium/hyper#2112

See the following Rollbar payload:

{
  "body": {
    "trace": {
      "frames": [
        {
          "lineno": 259, 
          "filename": "/root/.cargo/registry/src/github.com-1ecc6299db9ec823/hyper-0.12.36/src/client/conn.rs"
        }, 
        {
          "method": "actix::init_application::{{closure}}::{{closure}}::h03cddbc1bd61d1cf", 
          "filename": ""
        }, 
        {
          "method": "std::panicking::rust_panic_with_hook::h71e6a073d87de1f5", 
          "lineno": 595, 
          "filename": "/rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0/library/std/src/panicking.rs"
        }, 
        {
          "method": "std::panicking::begin_panic::{{closure}}::h84a4ac6142ac8c51", 
          "filename": ""
        }, 
        {
          "method": "std::sys_common::backtrace::__rust_end_short_backtrace::h8df64b270704a2ee", 
          "filename": ""
        }, 
        {
          "method": "std::panicking::begin_panic::hbb31f5852bbdf237", 
          "filename": ""
        }, 
        {
          "method": "futures::future::chain::Chain<A,B,C>::poll::h3a95f13ed59d540e", 
          "filename": ""
        }, 
        {
          "method": "<futures::future::map_err::MapErr<A,F> as futures::future::Future>::poll::hfa0f91984607d4e8", 
          "filename": ""
        }, 
        {
          "method": "<futures::future::map::Map<A,F> as futures::future::Future>::poll::h4934b71eb53f71a3", 
          "filename": ""
        }, 
        {
          "method": "futures::future::chain::Chain<A,B,C>::poll::h71d6c440b50f4359", 
          "filename": ""
        }, 
        {
          "method": "futures::future::chain::Chain<A,B,C>::poll::hd3fe1a06fbd9db6b", 
          "filename": ""
        }, 
        {
          "method": "<futures::future::poll_fn::PollFn<F> as futures::future::Future>::poll::h84a35bb95baa4eaa", 
          "filename": ""
        }, 
        {
          "method": "<hyper::client::ResponseFuture as futures::future::Future>::poll::h9088ea04a6a9a727", 
          "filename": ""
        }, 
        {
          "method": "<futures::future::map::Map<A,F> as futures::future::Future>::poll::h3e432334c050d77b", 
          "filename": ""
        }, 
        {
          "method": "<futures::future::map_err::MapErr<A,F> as futures::future::Future>::poll::hfac78dc6d9fd7b21", 
          "filename": ""
        }, 
        {
          "method": "futures::task_impl::std::set::h7edfc0098bc68c22", 
          "filename": ""
        }, 
        {
          "method": "std::thread::local::LocalKey<T>::with::he853f51dd671a8e7", 
          "filename": ""
        }, 
        {
          "method": "tokio_current_thread::Entered<P>::block_on::hfce4221cafa84bff", 
          "filename": ""
        }, 
        {
          "method": "tokio_executor::global::with_default::h1b74ce8974ffcfbe", 
          "filename": ""
        }, 
        {
          "method": "tokio_timer::timer::handle::with_default::h5e10e3d7fcaffb21", 
          "filename": ""
        }, 
        {
          "method": "tokio_reactor::with_default::h65ab2eac53ad4746", 
          "filename": ""
        }, 
        {
          "method": "tokio::runtime::current_thread::runtime::Runtime::block_on::hf78c57ace46f88d2", 
          "filename": ""
        }, 
        {
          "method": "std::sys_common::backtrace::__rust_begin_short_backtrace::hf7994801795d86a3", 
          "filename": ""
        }, 
        {
          "method": "core::ops::function::FnOnce::call_once{{vtable.shim}}::h3052f9825eb4eaf4", 
          "filename": ""
        }, 
        {
          "method": "<alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::h61144a2be4ee36d8", 
          "lineno": 1521, 
          "filename": "/rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0/library/alloc/src/boxed.rs"
        }, 
        {
          "method": "<alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::hcf5d395fdd120c17", 
          "lineno": 1521, 
          "filename": "/rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0/library/alloc/src/boxed.rs"
        }, 
        {
          "method": "std::sys::unix::thread::Thread::new::thread_start::hb5e40d3d934ebb7a", 
          "lineno": 71, 
          "filename": "/rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0/library/std/src/sys/unix/thread.rs"
        }, 
        {
          "method": "start_thread", 
          "filename": ""
        }, 
        {
          "method": "clone", 
          "filename": ""
        }
      ], 
      "exception": {
        "message": "dispatch dropped without returning error", 
        "class": "<panic>", 
        "description": "dispatch dropped without returning error"
      }
    }
  }, 
  "uuid": "f4c92254bf3e416ab6fb8e7db0d9b4ce", 
  "language": "rust", 
  "level": "error", 
  "timestamp": 1630532885, 
  "title": "dispatch dropped without returning error", 
  "custom": {}, 
  "environment": "PRODUCTION", 
  "framework": "unknown", 
  "metadata": {}
}

We have an Actix app (the actix::init_application in the trace) that at the very start does report_panics!, and then when an error occurs during any of the endpoint handlers we do:

                rollbar.build_report()
                    .from_message(&format!("{}", error))
                    .with_level("error")
                    .with_metadata(metadata_json)
                    .send();

We aren't using hyper anywhere else, aside from indirectly through rollbar-rs, so from what I can gather from the above trace, the rollbar.build_report()...send(); code panics within hyper with the dispatch dropped without returning error message, and that panic is caught in the hook set up by report_panics! and then successfully sent to Rollbar.

In the aforementioned hyper issue, @seanmonstar states (IIUC) that this panic can arise when the tokio executer drops the background tasks spawned by the hyper client before those tasks have managed to determine if the connection was closed, and that this can happen when the client is used from multiple executers.

I see in

rollbar-rs/src/lib.rs

Lines 521 to 537 in b4ad68a

	let job = self
	.http_client
	.request(request)
	.map(|res| Some(ResponseStatus::from(res.status())))
	.map_err(|error| {
	println!("Error while sending a report to Rollbar.");
	print!("The error returned by Rollbar was: {:?}.\n\n", error);
	None::<ResponseStatus>
	});
	thread::spawn(move || {
	current_thread::Runtime::new()
	.unwrap()
	.block_on(job)
	.unwrap()
	})

Maybe there's something about how the client is used in conjunction with tokio's current_thread::Runtime that's not safe when using the same rollbar client (which then in turn means reusing the same hyper client)?

SSL handling

The crate currently uses a rather old version of hyper-openssl. This version of the crate is not compatible with recent versions of OpenSSL (e.g. the one that ships out of the box on newer MacOS versions). It'd make sense to bump to a newer OpenSSL version, however I think the more sensible approach would be to use hyper-tls which internally depends on native-tls which will use the platform's native TLS stack or fall back to OpenSSL if there isn't one.

I'm up to preparing a PR for either one, I just want to know if you'd prefer bringing hyper-openssl up to date or going the native-tls route?

Code context of reported occurrences

Hi folks!

Rollbar engineer here, I found here via a customer of ours who found that grouping is weird.

I found that the occurrences reported by this SDK have code field in the stack frames that looks like a memory address or something like that. I'm not familiar with Rust, but that field is supposed to be a snippet of the source code of that stack frame.

I'd just like to let you know that by default we take the code fields of all stack frames into account for fingerprinting, so if the code reported to Rollbar is not consistent (e.g. changes between running the same application multiple times), grouping will not really work.

Extend comment to explain why we shouldn't join the thread for the panic example.

Hi,
Can we extend this comment here on not joining the thread in the panic handler with an explanation as to why? without joining, I worry that any panic crashing my program will be lost and not submitted to rollbar (which is what happens in the example given).

Parse the backtrace

Right now the backtrace is stored as a wall of text and sent to Rollbar and because of this it is really hard to understand. We should parse it and print it properly inside the Frames.

Macros refer to backtrace unqualified

The macros currently refer to the backtrace crate with a not fully qualified path, e.g. like here:

rollbar-rs/src/lib.rs

Line 19 in 886ee78

let backtrace = backtrace::Backtrace::new();

This causes errors like

error[E0433]: failed to resolve. Use of undeclared type or module `backtrace`
   --> src/main.rs:125:9
    |
125 |         report_panics!(client);
    |         ^^^^^^^^^^^^^^^^^^^^^^^ Use of undeclared type or module `backtrace`
    |
    = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

unless you put an extern crate backtrace; and use backtrace; all over the place, since the macro is expanded with the scope of the invocation, where backtrace might not be defined at all.

Since rollbar-rs already correctly pulls in backtrace as a dependency it should just use the fully qualified path (::backtrace::Backtrace::new()).

Integration with "failure" crate?

Hey! I'm working on a project that uses "failure" for errors. Its Error type has backtraces pointing back to where the error originated. Is it possible for report_error! to use that backtrace instead of creating a new one?

How to send data in the `custom` field?

First, thank you for this library!

Second, I have a bunch of contextual data I'd like to send in the report, but I don't see an any way to do this. From https://rollbar.com/docs/api/items_post/ :

    // Optional: custom
    // Any arbitrary metadata you want to send. "custom" itself should be an object.
    "custom": {},

What would you recommend?

Is this repo dead?

This repo has not had what looks like any significant changes in 2 years, is it dead?

Documentation Link redirects to a different website

On this repository's Readme, there is a documentation link for https://roxasshadow.github.io/rollbar-rs.

Upon clicking said link, we are redirected to https://www.giovannicapuano.net/rollbar-rs which doesn't appear to work at the moment.

Is there an alternative link for documentation? Seems like Rust Docs are sufficient coupled with the examples folder