Rollbar.error has less context than uncaught exceptions

[Paul-Yves]

Uncaught exceptions in Rails are reported to rollbar with stacktrace and context such as request parameters.
However if we replace :

may_raise_exception()

by

begin
  may_raise_exception()
rescue TheExceptionClass => error
  return if should_fail_silently(error) # sometimes the exception should not be raised
  Rollbar.error(error)
end

I noticed a loss of context, I no longer have request param for example. I still have the proper stacktrace though so the part of the doc I read did not really helped me and I was wondering if it was a known issue and if there was something I could do to keep the maximum amount of context.

[PierreND]

I am also interested

[waltjones]

Hi all, I haven't been able to reproduce this. When calling Rollbar methods with the default Rollbar instance, during the request lifecycle, the request context does get added to the request. If anyone has details that might help reproduce this, I'll try it.

In case it's helpful, here is some background on how the request context is added.

This is implemented in rollbar-gem using scopes. https://docs.rollbar.com/docs/ruby#the-scope

The initialization of the scope that is used with uncaught exceptions is here: https://github.com/rollbar/rollbar-gem/blob/master/lib/rollbar/middleware/rails/rollbar.rb#L20-L22

That scope, containing the request and context, is added to the default Rollbar instance, and should be available for payloads anywhere Rollbar.log, Rollbar.error, etc. are called using the default Rollbar instance during the execution of the request. This also works when sending messages with no exception, e.g. Rollbar.info('Test message').

Exceptions to this:

The scope is set when entering the Rollbar middleware (request path) and removed when exiting (response path). Outside of this, the scope is cleared. This should work as expected for any Rollbar calls during the request lifecycle, but will be empty after the response is sent.

If multiple Rollbar instances are created, they will inherit the current scope of the parent instance at the time they are created, but their scope will not be updated later when the default instance is updated. Generally, their scope will not be automatically updated with each new incoming request.

Some job queues (Sidekiq, DelayedJob) have plugins that add their own scope. These are typically not executing during the request, though some senders have a synchronous option.

[Paul-Yves]

Ok, I could not reproduce by directly putting this code in a controller, however I could reproduce when putting it in a sidekiq::job. I do not event need to be in a rescue, if I create a job directly calling Rollbar.error, I loose context such as the name of the job or the parameters it was called with.